Resultados 1 a 6 de 6
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    [EN] NSA persuaded RSA to undermine commercial encryption systems

    The US National Security Agency persuaded web-encryption company RSA to develop a more vulnerable random-number generator to make it easier to spy on businesses, Reuters has reported.

    The news agency reported research suggesting the software had made reading companies' encrypted messages about 65,000 times easier.

    RSA said it should "have been more sceptical of NSA's intentions".

    The NSA declined to comment on any collaboration with RSA.

    The research followed the description of a project to undermine commercial encryption systems in papers leaked by former NSA systems administrator Edward Snowden, published in late 2013.

    Proving unpopular

    RSA chief technology officer Sam Curry told Reuters it had trusted the NSA because of the agency's role in securing communications and critical infrastructure for the US government.

    He added the NSA-inspired random-number generator had been removed from its product line after proving unpopular with customers.

    In December 2013, Reuters reported the NSA had paid RSA $10m (£6m) to insert a flaw or "backdoor" into another, more widely used, software module that also generated random numbers to help with encryption.

    At that time, RSA "categorically denied" that accusation and said it had not signed any secret deal with the NSA.

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    NSA infiltrated RSA security more deeply than thought

    Security industry pioneer RSA adopted not just one but two encryption tools developed by the U.S. National Security Agency, greatly increasing the spy agency's ability to eavesdrop on some Internet communications, according to a team of academic researchers.

    Reuters reported in December that the NSA had paid RSA $10 million to make a now-discredited cryptography system the default in software used by a wide range of Internet and computer security programs. The system, called Dual Elliptic Curve, was a random number generator, but it had a deliberate flaw - or "back door" - that allowed the NSA to crack the encryption.

    A group of professors from Johns Hopkins, the University of Wisconsin, the University of Illinois and elsewhere now say they have discovered that a second NSA tool exacerbated the RSA software's vulnerability.

    The professors found that the tool, known as the "Extended Random" extension for secure websites, could help crack a version of RSA's Dual Elliptic Curve software tens of thousands of times faster, according to an advance copy of their research shared with Reuters.

    While Extended Random was not widely adopted, the new research sheds light on how the NSA extended the reach of its surveillance under cover of advising companies on protection.

    RSA, now owned by EMC Corp, did not dispute the research when contacted by Reuters for comment. The company said it had not intentionally weakened security on any product and noted that Extended Random did not prove popular and had been removed from RSA's protection software in the last six months.

    "We could have been more skeptical of NSA's intentions," RSA Chief Technologist Sam Curry told Reuters. "We trusted them because they are charged with security for the U.S. government and U.S. critical infrastructure."

    Curry declined to say if the government had paid RSA to incorporate Extended Random in its BSafe security kit, which also housed Dual Elliptic Curve.

    An NSA spokeswoman declined to comment on the study or the intelligence agency's motives in developing Extended Random.

    The agency has worked for decades with private companies to improve cybersecurity, largely through its Information Assurance Directorate. After the 9/11 attacks, the NSA increased surveillance, including inside the United States, where it had previously faced strict restrictions.

    Documents leaked by former NSA contractor Edward Snowden showed that the agency also aimed to subvert cryptography standards. A presidential advisory group in December said that practice should stop, though experts looking at the case of Dual Elliptic Curve have taken some comfort in concluding that only the NSA could likely break it.

    "It's certainly well-designed," said security expert Bruce Schneier, a frequent critic of the NSA. "The random number generator is one of the better ones."


    Cryptography experts have long been suspicious of Dual Elliptic Curve, but the National Institute of Standards and Technology and RSA only renounced the technology after Snowden leaked documents about the back door last year.

    That was also when the academic team set out to see if they could break Dual Elliptic Curve by replacing two government-issued points on the curve with their own. The team published a summary of their study online on Monday (

    and plan to present their full findings at a conference this summer.

    Random numbers are used to generate cryptographic keys - if you can guess the numbers, you can break the security of the keys. While no random number generator is perfect, some generators were viewed as more predictable than others.

    In a Pentagon-funded paper in 2008, the Extended Random protocol was touted as a way to boost the randomness of the numbers generated by the Dual Elliptic Curve.

    But members of the academic team said they saw little improvement, while the extra data transmitted by Extended Random before a secure connection begins made predicting the following secure numbers dramatically easier.

    "Adding it doesn't seem to provide any security benefits that we can figure out," said one of the authors of the study, Thomas Ristenpart of the University of Wisconsin.

    Johns Hopkins Professor Matthew Green said it was hard to take the official explanation for Extended Random at face value, especially since it appeared soon after Dual Elliptic Curve's acceptance as a U.S. standard.

    "If using Dual Elliptic Curve is like playing with matches, then adding Extended Random is like dousing yourself with gasoline," Green said.

    The NSA played a significant role in the origins of Extended Random. The authors of the 2008 paper on the protocol were Margaret Salter, technical director of the NSA's defensive Information Assurance Directorate, and an outside expert named Eric Rescorla.

    Rescorla, who has advocated greater encryption of all Web traffic, works for Mozilla, maker of the Firefox web browser. He and Mozilla declined to comment. Salter did not respond to requests for comment.

    Though few companies appear to have embraced Extended Random, RSA did. The company built in support for the protocol in BSafe toolkit versions for the Java programming language about five years ago, when a preeminent Internet standards group - the Internet Engineering Task Force - was considering whether to adopt Extended Random as an industry standard. The IETF decided in the end not to adopt the protocol.

    RSA's Curry said that if Dual Elliptic Curve had been sound, Extended Random would have made it better. "When we realized it was not likely to become a standard, we did not enable it in any other BSafe libraries," he added.

    The academic researchers said it took about an hour to crack a free version of BSafe for Java using about $40,000 worth of computer equipment. It would have been 65,000 times faster in versions using Extended Random, dropping the time needed to seconds, according to Stephen Checkoway of Johns Hopkins.

    The researchers said it took them less than 3 seconds to crack a free version of BSafe for the C programming language, even without Extended Random, because it already transmitted so many random bits before the secure connection began. And it was so inexpensive it could easily be scaled up for mass surveillance, the researchers said.

  3. #3
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    Logo original mostrava a cara lavada

    The NSA played a significant role in the origins of Extended Random. The authors of the 2008 paper on the protocol were Margaret Salter, technical director of the NSA's defensive Information Assurance Directorate, and an outside expert named Eric Rescorla.

    Rescorla, who has advocated greater encryption of all Web traffic, works for Mozilla, maker of the Firefox web browser. He and Mozilla declined to comment. Salter did not respond to requests for comment.
    Mozilla fez de novo, Mozilla fez pior.

    Mais uma vez a fundação/empresa Mozilla aparece mergulhada até o pescoço em encrenca da grossa.

    Os ratos abandonaram rapidinho a canoa furada.

    "Three Mozilla board members have reportedly resigned over the organisation's pick for CEO, but not for his stance on same-sex marriage."

    The Wall Street Journal reported on Saturday that former Mozilla CEOs Gary Kovacs and John Lilly, and Shmoop CEO Ellen Siminoff left the board of the non-profit organisation last week, reportedly because they were seeking a CEO outside of the company with experience in the mobile industry who could advance the plans for Mozilla's Firefox OS mobile platform.

    Não parece uma coisa, nem outra.
    Última edição por 5ms; 01-04-2014 às 13:56.

  4. #4
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    On the Practical Exploitability of Dual EC in TLS Implementations

  5. #5
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    In September 2013, the New York Times, the Guardian and ProPublica reported on a secret National Security Agency SIGINT Enabling Project with the mission to “actively [engage] the US and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs.” The project aims to influence commercial encryption products to make the encrypted connections vulnerable to electronic surveillance. Named targets include protocols for “TLS/SSL, https (e.g., webmail), SSH, encrypted chat, VPNs and encrypted VOIP.”
    In particular, leaked NSA documents indicate that particular NIST and ISO cryptography standards may have been influenced by the NSA in order to weaken the security of U.S. and non-US cryptography products. These standards include NIST Special Publication 800-90A and ISO 18031, both of which contain algorithms for generating the random numbers used, for example, to generate keys for cryptographic systems.
    One of the algorithms contained within these documents is a pseudorandom number generator called the Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG) that has long been known to admit a serious potential back door in the event that an attacker generates the standard algorithm parameters. While no one is claiming that NIST or NSA designed the generator to facilitate such attacks, the September 2013 news appears to provide evidence for this possibility.
    Use of Dual EC in TLS Libraries

    Despite Shumow and Ferguson's warning in 2007, several cryptographic software vendors have implemented Dual EC in their products. For example, both Microsoft’s SChannel (used in Microsoft Internet Explorer and IIS) and OpenSSL’s FIPS module include Dual EC as an optional random number generator. Moreover, RSA’s BSAFE crypto libraries use Dual EC as the default random number generator.
    A primary use-case for each of the aforementioned software libraries is to establish encrypted SSL/TLS connections, which are used for secure web browsing, email transfer, VPNs and many other applications. The authors study to what extent TLS/SSL connections established by these software libraries are vulnerable to attacks using the Dual EC back door, assuming that an attacker knows a trapdoor for the Dual EC parameters.
    To conduct this research, the authors reverse-engineered several libraries, including RSA BSAFE Share for C/C++, RSA BSAFE Share for Java, Microsoft SChannel, and OpenSSL, in order to replace the existing Dual EC parameters with those of their own devising. In the case of Share for C/C++, Share for Java and SChannel, identifying the Dual EC parameters and disabling relevant diagnostics required substantial reverse engineering effort. They then determined to what extent TLS connections made by these libraries were vulnerable to attacks on Dual EC DRBG.
    Surprisingly, the previously known attacks do not tell the entire story. They do not consider many important implementation-specific decisions, in particular the amount of generator output revealed, the alignment of outputs, the use of additional entropy, and even critical bugs in Dual EC implementations.
    Summary of the results

    The researchers analyzed the use of Dual EC in four recent TLS/SSL library implementations: RSA BSAFE Share for C/C++, RSA BSAFE Share for Java, Microsoft SChannel, and OpenSSL. The major findings are as follows:

    • The RSA BSAFE implementations of TLS make the Dual EC back door particularly easy to exploit compared to the other libraries analyzed. The C version of BSAFE makes a drastic speedup in the attack possible by broadcasting long contiguous strings of random bytes and by caching the output from each generator call. The Java version of BSAFE includes fingerprints in connections, making it relatively easy to identify them in a stream of network traffic.
    • SChannel does not implement the current Dual EC standard: it omits one step of the Dual EC algorithm. This omission does not prevent attacks; in fact, it makes them slightly faster.
    • A previously unknown bug was discovered in OpenSSL that prevented the library from running when Dual EC is enabled. It is still conceivable that someone is using Dual EC in OpenSSL, since the bug has an obvious and very easy fix which was applied in order to evaluate the resulting version of OpenSSL, which the paper calls “OpenSSL-fixed.” OpenSSL-fixed turns out to provide additional entropy (“additional input”) with each call to the library. In practice, this additional input can make attacks significantly more expensive than for the other libraries.

    Evidence of an implementation of a non-standard TLS extension called “Extended Random” was discovered in the RSA BSAFE products. This extension, co-written at the request of the National Security Agency, allows a client to request longer TLS random nonces from the server, a feature that, if it enabled, would speed up the Dual EC attack by a factor of up to 65,000. In addition, the use of this extension allows for for attacks on Dual EC instances configured with P-384 and P-521 elliptic curves, something that is not apparently possible in standard TLS. While the code implementing Extended Random was not compiled into the build of Share for C/C++ examined, it was available (though deactivated) in the build of Share for Java that was analyzed. In the latter case, the researchers were able to re-enable it and verify the functionality. Note that the attack times reported below do not take advantage of extended random.
    The results are summarized in the following table.
    Library Default PRNG Extended Random Bytes per Session Additional Entropy Time (minutes)
    BSAFE C 31–60 0.04
    BSAFE Java 28 63.96
    SChannel I 28 62.97
    SChannel II 30 182.64
    OpenSSL-fixed I 32 220 0.02
    OpenSSL-fixed III 32 235+k 2k⋅83.32

    Each of the rows above describes a TLS library in a particular attack scenario. The rightmost column indicates the time required to achieve full decryption of a TLS connection on the small 16-CPU computer cluster used in the experiments. The “Default PRNG” column indicates whether the Dual EC algorithm is specified as the default random number generator, or must be activated by the calling application. “Extended Random” indicates whether code for the Extended Random extension was present in the library analyzed. The “Additional Entropy” column indicates how much “additional input” entropy is provided to the generator on each call to the generator. In the case of OpenSSL-Fixed III it is assumed that an additional input entropy of k bits is used.
    As illustrated above, TLS connections made by RSA Share for C/C++ could be decrypted in several seconds on the cluster and in under a minute on an old laptop. Other libraries, such as Share for Java, Microsoft SChannel, and OpenSSL (with the bug repaired) also proved feasible to attack, but were in some cases significantly more costly. Indeed, depending on the design choices in the implementations, an attacker can recover TLS session keys within seconds on a single CPU or may require a cluster of more than 100,000 CPUs for the same task if a different library is used. Note that the speed results are due to custom, highly-optimized attack implementations. Less efficient implementations may take significantly more time.

  6. #6
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Measurement Study

    Finally, the prevalence of these libraries on the Internet was studied. Initiating a ZMap scan over the entire IPv4 address space, TLS handshake data from 21.8 million servers responding to public https requests was collected. Using the known handshake fingerprint exhibited by BSAFE, as well as a pattern discovered in the session identifiers produced by SChannel servers, the researchers were able to identify the presence of these implementations from handshake data alone. They found that:

    • The Java version of BSAFE is not prevalent on public-facing https servers—only 720 servers were found (much less than 1%) that exhibit the fingerprint. Closer examination revealed that one third of these correspond to one particular software package (Apache Coyote/1.1).
    • SChannel is far more prevalent, comprising approximately 2.7 million servers (12%) of those scanned.

    There are two important points to make regarding these results. First, the number of BSAFE servers found is a lower bound for the true number of running BSAFE implementations—because the C++ version does not exhibit a handshake fingerprint by default and there does not appear to be a reliable way to identify it remotely. Second, the SChannel fingerprint does not indicate whether Dual EC is in use on the server. It is not enabled by default on Windows, so the servers observed are not all vulnerable to Dual EC attacks.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens