Home Tags Triple DES

Tag: Triple DES

Crypto needs more transparency, researchers warn

Publish primes with seeds, so we know there are no backdoors Researchers with at the French Institute for Research in Computer Science and Automation (INRIA) and the University of Pennsylvania have called for security standards-setters to publish the seeds for the prime numbers on which their standards rely. The boffins also demonstrated again that 1,024-bit primes can no longer be considered secure, by publishing an attack using “special number field sieve” (SNFS) mathematics to show that an attacker could create a prime that looks secure, but isn't. Since the research is bound to get conspiracists over-excited, it's worth noting: their paper doesn't claim that any of the cryptographic primes it mentions have been back-doored, only that they can no longer be considered secure. “There are opaque, standardised 1024-bit and 2048-bit primes in wide use today that cannot be properly verified”, the paper states. Joshua Fried and Nadia Heninger (University of Pennsylvania) worked with Pierrick Gaudry and Emmanuel Thomé (INRIA at the University of Lorraine on the paper, here. They call for 2,048-bit keys to be based on “standardised primes” using published seeds, because too many crypto schemes don't provide any way to verify that the seeds aren't somehow back-doored. Examples of re-used primes in the paper include: Many TLS implementations use some form of default, and as a result, “in May 2015, 56 per cent of HTTPS hosts selected one of the 10 most common 1024-bit groups when negotiating ephemeral Diffie-Hellman key exchange”; In IPSec, “66 per cent of IKE responder hosts preferred the 1024-bit Oakley Group 2 over other choices” for their Diffie-Hellman exchange; and OpenSSH implementations favour “a pre-generated list that is generally shipped with the software package”. If any of the “hard-coded” primes were maliciously produced – something that's happened before, for those who remember RSA's NSA-funded Dual EC Deterministic Random Bit Generator – it would be hard to spot by looking at the numbers, but factorisation would be feasible. It might not necessarily be easy, however: the paper describing the SNFS computation notes it needed “a little over two months of calendar time on an academic cluster” (using between 500 and 3,000 cores in different phases in the operation – a total of around 400 core-years). Their experiments ran on France's Grid'5000 testbed, the University of Pennsylvania's Cisco UCS cluster, the University of Waterloo's CrySIP RIPPLE facility, and Technische Universiteit Eindhoven's Saber cluster. Earlier this year, INRIA researchers turned up the Sweet32 birthday attack against old Blowfish and Triple DES ciphers, and in January the group warned the world that the zombie MD5 and SHA1 hash protocols live on in too many TLS, IKE and SSH implementations. ®

OpenSSL swats a dozen bugs, one notable nasty

Denial of service dross dead. A dozen flaws have been patched in OpenSSL, including one high severity hole that allows denial of service attacks. The OpenSSL Project pushed patches in versions 1.1.0a, 1.0.2i and 1.0.1u, with most of the flaws flagged as low severity risks. The nastiest vulnerability (CVE-2016-6304) results when attackers issue a massive OCSP status request extension which exhausts memory on servers in default configuration. Researcher Shi Lei of vulnerability blitzkrieg house Qihoo 360 spotted that one. Admins can mitigate damage by running no-ocsp or by running older versions of OpenSSL below 1.0.1g. Another moderate severity denial of service flaw (CVE-2016-6305) is fixed in the patch run which affects 1.0 of OpenSSL. The OpenSSL project nixed risky ciphers in version 1.1 to squash the so-called Sweet32 exploit which is a birthday attack against 64-bit ciphers like Blowfish and Triple DES. Cisco said it was difficult to exploit. “For a successful attack, a large amount of data has to be sent one-way during the session, and the session has to be encrypted using the same key," Borg security engineers said. "For 64-bit ciphers, it would take about 32GB of data in order to have a 50 percent probability of collision in any of the cipher blocks”. ®

Citrix swats Sweet32 bug by just turning off old ciphers

You can even leave out the turning it on again - this bug's not worth its brand, really Citrix has pushed back a little against the dangers posed to its users by the Sweet32 “birthday attack” against old ciphers. The attack, published in late August, is a birthday attack against 64-bit ciphers like Blowfish and Triple DES. That's prompted various vendors to get patching, but as Citrix explains in this blog post, deploying a Sweet32 attack in the real world is non-trivial. “For a successful attack, a large amount of data has to be sent one-way during the session, and the session has to be encrypted using the same key.

For 64-bit ciphers, it would take about 32GB of data in order to have a 50% probability of collision in any of the cipher blocks”, the post states. Moreover: “since these protocols use different keys for each direction of the channel, the attacker can only utilise data from one side of the connection, and not both sides combined”. Citrix says its recommendation is to disable the old 64-bit ciphers anyhow, and switch to AES-based encryption. Patches for Sweet32 have already landed from OpenSSL (which has pushed weak ciphers out of its default configuration); and Mozilla, which is rate-limiting all ciphersuites. ®

Yes, you can hack cell phones like on Mr. Robot—just not...

EnlargeNBCUniversal Warning: This piece contains minor spoilers for the most recent episode of Mr. Robot (S2E9) reader comments 1 Share this story Time and time again, Mr. Robot has proven to be a show that prides itself on extreme attention to detail. Whether it involves hiring ex-FBI employees as consultants or tracking down the duo behind the Full House theme, the series wants to ground its high-stakes story in a healthy dose of realism.  “The notion of there being an E-Corp, a conglomerate in charge of 70 percent of the world’s debt, is a big pill to swallow," Kor Adana, staff writer and the show's lead tech producer, told Ars recently. "The way I see it, anything we can do to ground the show in reality with all the other tools at our disposal, the better it is to sell this version of reality." In the series' latest episode, hero-hacker Elliot Alderson launches an attack script called crackSIM from a real-world device—Pwnie Express' PwnPhone—to allow him to eavesdrop on a cell phone call.

As superhuman as the attack seems, it's yet another realistic portrayal from Adana and his team. Yes, this hack is technically possible.
It's also possible for an attacker to eavesdrop on a cell phone call.

But this being a ~50 minute cable series, creative license does ultimately rear its head.

And unfortunately, the hack Elliot used wouldn't work to do the eavesdropping as we understand infosec today.
Instead, the show (rightfully) took a few artistic liberties when demonstrating how such an attack would happen. Download video PwnieExpress / NBCUniversal A Pwnie party Ars got a bit of a preview of the attack from the folks at Pwnie Express.

As they discussed with us on this week's Decrypted podcast (embedded below), the company was contacted by the producers of Mr. Robot to take part in the plot. Pwnie was able to take a small role in discussing what is and isn't capable with the series staff during production, and ultimately the team was thrilled with the results. (After all, as the clip above shows, Elliot calls the phone the ultimate hacking device. Later in the episode, this attack earns him the title of "master" from a group of international hacker mercenaries called the Dark Army.) We've gone hands on with the Pwn Phone in its previous incarnation and once even used a similar device on an NPR reporter (don't worry, he agreed to it).

But since the Pwn Phone plays such a prominent role in this hack on this show, we wanted to talk with Pwnie's vice president of marketing Dmitri Vlachos and director of product development (and former Air Force cyber operator) Yolanda Smith about this "crackSIM" attack.

Even if it's been fictionalized, could someone pull off what Elliot was doing in the real world? Enlarge / The original Pwn Phone, with its external Wi-Fi adaptor case jacked into its USB port, as we saw it in 2014. CrackSIM is not included by default on the Pwn Phone, and that's because it is a fake program scripted by Elliot within the show's universe.

But Smith said there's research that suggests the capability of crackSIM, which broke the encryption on the SIM card, is plausible. Research presented by Karsten Nohl of Security Research Labs at last year's Black Hat demonstrated that if an attacker had physical access to a SIM card, a hard disk full of pre-computed potential keys, and full knowledge of what the response from a phone for an Over The Air (OTA) update message would be, it was possible to grab a single 56-bit DES encryption key from the SIM.

Even SIMs that use Triple DES encryption sometimes downgrade their key to just normal DES when the service they're connected to requests it.

This is the sort of attack that is used in "Stingray" boxes, devices used by law enforcement to track cell phones and intercept their calls. However, Elliot's hack took only seconds.

And that is where, as Smith put it, the show took a bit of "dramatic license." Elliot also appears to clone the SIM card to use it to intercept calls and listen in on his targets rather than intercepting the call Stingray style—a hack that would just give the attacker the ability to imitate the victim and take control of the hacked phone's number rather than intercepting calls.

That's precisely what happened earlier this year when someone took over Black Lives Matter activist DeRay McKesson's phone number and got access to his Twitter account and other accounts through password resets authenticated from the hijacked number. When asked how she would pull off the hack herself, Smith said that the most likely route would be to exploit a known weakness in the SS7 phone network routing protocol. An attacker could, using the victim's phone number, essentially route all the calls to that number through a proxy, allowing "man-in-the-middle" monitoring of calls and SMS messages. (Black Hat, DEFCON, et al: If you're listening, we're ready for next year's Mr. Robot panel.) Another real world alternative would require proximity to the victim—using a femtocell to intercept the calls.

A hacked femtocell would allow direct monitoring of the call without having to crack the SIM, because the femtocell decrypts signals it receives to route them over the Internet. Regardless of the series' staff stretching the truth a tad, the fact that a cable television show is going through the trouble of featuring the Pwn Phone in the first place, and working with consultants and PwnieExpress to ensure the highest degree of realism possible speaks volumes about Mr. Robot and overall interest in modern day infosec. Hopefully, the days of CSI: Cyber-types are long behind us. Note: PwnieExpress enjoyed its Mr. Robot experience so much that the company is promoting the unexpected publicity by offering a giveaway of a Pwn Phone through a contest. Pwnie is also posting links to downloads that will let individuals turn their own Android devices into Pwn Phones. Hear more from the PwnieExpress team about their big cameo (and from one of the writers responsible for last week's episode, Lucy Teitler) on our latest Decrypted podcast.
If you have feedback, show ideas, or even questions for future weeks, get in touch through the comments section, on iTunes, or via e-mail. Host Nathan Mattise will totally upvote your comments in exchange for iTunes ratings.

Listen Direct Download URL (latest episode): Decrypted, Ep. 9: How do you write answers for Mr. Robot's big questions?" Listen or subscribe on Stitchr Listen or subscribe on Soundcloud Subscribe via RSS Subscribe via the iTunes store Also look for Decrypted in podcast listings of the Google Play Music store

Big data busts crypto: ‘Sweet32’ captures collisions in old ciphers

Boffins blow up Blowfish and double down on triple DES Researchers with France's INRIA are warning that 64-bit ciphers – which endure in TLS configurations and OpenVPN – need to go for the walk behind the shed. The research institute's Karthikeyan Bhargavan and Gaëtan Leurent have demonstrated that a man-in-the-middle on a long-lived encrypted session can gather enough data for a “birthday attack” on Blowfish and triple DES encryption. They dubbed the attack “Sweet32”. Sophos' Paul Ducklin has a handy explanation of why it matters here. The trick to Sweet32, the Duck writes, is the attackers worked out that with a big enough traffic sample, any repeated crypto block gives them a start towards breaking the encryption – and collisions are manageably common with a 64-bit block cipher like Blowfish or Triple-DES. They call it a “birthday attack” because it works on a similar principle to what's known as the “birthday paradox” – the counter-intuitive statistic that with 23 random people in a room, there's a 50 per cent chance that two of them will share a birthday. In the case of Sweet32 (the 32 being 50 per cent of the 64 bits in a cipher), the “magic number” is pretty big: the authors write that 785 GB of captured traffic will, under the right conditions, yield up the encrypted HTTP cookie and let them decrypt Blowfish- or Triple-DES-encrypted traffic. If you do it right, and here begins the TL;dr part. To launch the attack, you need to: Get a victim to visit a malicious site (site A) – one that they have to log into. The victim's login sets an HTTP cookie the browser uses for future requests; Pass the victim on to Site B, which generates millions of JavaScript requests to Site A, using the login cookie given to the victim; Keep the connection alive long enough to store 785 GB of encrypted data blocks, and look for a collision; Decrypt the login cookie. Decryption is still the hard part: the researchers note that it's far from an instant process: On Firefox Developer Edition 47.0a2, with a few dozen workers running in parallel, we can send up to 2,000 requests per second in a single TLS connection. In our experiment, we were lucky to detect the first collision after only 25 minutes (220.1 requests), and we verified that the collision revealed [the plaintext we were after …The full attack should require 236.6 blocks (785 GB) to recover a two-block cookie, which should take 38 hours in our setting. Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours. As they note, however, long-lived encrypted connections exist in at least one real-world setting: VPN sessions. “Our attacks impact a majority of OpenVPN connections and an estimated 0.6% of HTTPS connections to popular websites. We expect that our attacks also impact a number of SSH and IPsec connections, but we do not have concrete measurements for these protocols” (emphasis added). For users, that means switching from 64-bit ciphers to 128-bit ciphers; or if you can't get the server to switch, set up your client to force frequent re-keying. Browser makers, TLS library authors and OpenVPN have been notified and are working on patches. ® Sponsored: Global DDoS threat landscape report

New collision attacks against triple-DES, Blowfish break HTTPS sessions

There is now a practical, relatively fast attack on 64-bit block ciphers that lets attackers recover authentication cookies and other credentials from HTTPS-protected sessions, a pair of French researchers said. Legacy ciphers Triple-DES and Blowfish need to go the way of the broken RC4 cipher: Deprecated and disabled everywhere. Dubbed Sweet32, researchers were able to take authentication cookies from HTTPS-protected traffic using triple-DES (3DES) and Blowfish and recover login credentials to be able to access victim accounts, said the researchers, Karthikeyan Bhargavan and Gaëtan Leurent of INRIA in France.

The attack highlights why it is necessary for sites to stop using legacy ciphers and upgrade to modern, more secure ciphers. "We show that a network attacker who can monitor a long-lived Triple-DES HTTPS connection between a web browser and a website can recover secure HTTP cookies by capturing around 785 GB of traffic.
In our proof-of-concept demo, this attack currently takes less than two days, using malicious Javascript to generate traffic," said Bhargavan and Leurent.

They are expected to present the full paper in October at the 23rd ACM Conference on Computer and Communications Security. Sweet32 is a collision attack against triple-DES (3DES) and Blowfish in cipher block chaining (CBC) mode.
In CBC mode, input collisions lead to XOR of two message blocks. When lots of message blocks are encrypted with the same key in this mode, collisions become more likely, which leads to getting the contents of two different message blocks as output.

Attackers can target a victim's authentication cookie by luring them to a malicious site and injecting JavaScript into the victim's browser. JavaScript repeatedly sends HTTP queries to a site the victim is logged into, and each request will include the authentication cookie. The researchers found that if the attackers send at least 232 queries and capture all the requests, they will eventually see a collision and be able to recover the contents of the cookie. "An important requirement for the attack is to send a large number of requests in the same TLS connection.

Therefore, we need to find client and servers that not only negotiate the use of Triple-DES, but also exchange a large number of HTTP request in the same TLS connection (without rekeying).

This is possible using a persistent HTTP connection, as defined in HTTP/1.1 (Keep-Alive). On the client side, all browsers that we tested (Firefox, Chrome, Opera) will reuse a TLS connection as long as the server keeps it open," the researchers said. Blowfish and 3DES are still supported in TLS, IPsec, SSH, and other protocols and well-known sites such as Nasdaq.com and Walmart.com still support these legacy ciphers.

The majority of OpenVPN connections and between 1 percent and 2 percent of the Internet's traffic may be susceptible to Sweet32, the researchers estimated.

The implementation used in OpenSSL is also affected, although the OpenSSL maintainers claimed the attack did not expose a critical weakness. OpenVPN 2.3.12 comes with a warning about Blowfish weaknesses and secure configuration advice for dealing with Sweet32. OpenSSL 1.0.2 and 1.0.1 will move 3DES from the "HIGH" keyword to "MEDIUM" keyword and support it by default, the newer OpenSSL 1.1.0 will no longer compile the cipher as part of the default build.

Administrators wanting to use the legacy cipher in OpenSSL 1.1.0 will need to use the ‘enable-weak-ssl-ciphers' configuration option, and even then, the cipher is allowed only in the ‘MEDIUM' keyword. Major browsers makers are making changes which would prioritize more secure ciphers over 3DES. The techniques and principles used to craft the attack are well-understood in cryptographic circles.

The researchers reduced the complexity and time needed to execute the attack. "While the principles behind this attack are well known, there's always a difference between attacks in principle and attacks in practice. What this paper shows is that we really need to start paying attention to the practice," wrote Matthew Green, cryptography expert and professor at Johns Hopkins University. Just because the attack is possible doesn't mean it is particularly easy to carry out.

For Sweet32, the attacker needs to be able to both monitor traffic passing between the end user and a vulnerable websites and control JavaScript on a webpage loaded by the user's browser.
It would take about 38 hours to collect hundreds of gigabytes of data necessary to decrypt the authentication cookie.

This attack scenario is very much a laboratory scenario, but it's still a good reminder that eventually these attacks will become easier to carry out. Enterprises and developers should treat 3DES and Blowfish in the same way they treat RC4: stop using it.

The complexity of Sweet32 is comparable to recently developed attacks against RC4, the researchers said. Researchers developing more ways to attack RC4 sped up its deprecation. Major web browsers no longer support RC4, and major websites such as Gmail have also entirely deprecated the cipher. Developers should stop using legacy 64-bit block-ciphers altogether.
In the case of Sweet32, that means disabling the Triple DES symmetric key cipher in TLS and retiring Blowfish in OpenVPN.

Ciphers with larger block sizes, such as AES, are immune from Sweet32.
Server administrators can also disable shorter ciphers entirely.

This would affect a small number of users who are still relying on older hardware and software. There is no need to wait till the attackers are easy and cheap to execute to get rid of weak and vulnerable cryptographic ciphers. Just as there is a concerted effort to ditch RC4, other 64-bit ciphers also need to go.

HTTPS and OpenVPN face new attack that can decrypt secret cookies

Enlarge / From an upcoming paper laying out a new attack against 64-bit block ciphers used by HTTPS and OpenVPN.Karthikeyan Bhargavan and Gaëtan Leurent reader comments 10 Share this story Researchers have devised a new attack that can decrypt secret session cookies from about 1 percent of the Internet's HTTPS traffic and could affect about 600 of the Internet's most visited sites, including nasdaq.com, walmart.com, match.com, and ebay.in. The attack isn't particularly easy to carry out because it requires an attacker to have the ability to monitor traffic passing between the end user and one of the vulnerable websites and to also control JavaScript on a webpage loaded by the user's browser.

The latter must be done either by actively manipulating an HTTP response on the wire or by hosting a malicious website that the user is tricked into visiting.

The JavaScript then spends the next 38 hours collecting about 785GB worth of data to decrypt the cookie, which allows the attacker to log into the visitor's account from another browser.

A related attack against OpenVPN requires 18 hours and 705GB of data to recover a 16-byte authentication token. Impractical no more Despite the difficulty in carrying out the attack, the researchers said it works in their laboratory and should be taken seriously.

They are calling on developers to stop using legacy 64-bit block-ciphers.

For transport layer security, the protocol websites use to create encrypted HTTPS connections, that means disabling the Triple DES symmetric key cipher, while for OpenVPN it requires retiring a symmetric key cipher known as Blowfish.

Ciphers with larger block sizes, such as AES, are immune to the attack. "It is well-known in the cryptographic community that a short block size makes a block cipher vulnerable to birthday attacks, even if the[re] are no cryptographic attacks against the block cipher itself," the researchers wrote in a blog post explaining the attacks. "We observe that such attacks have now become practical for the common usage of 64-bit block ciphers in popular protocols like TLS and OpenVPN." A birthday attack is a type of cryptographic exploit that is based on the mathematical principle known as the birthday paradox.
It holds that in a room of 23 randomly selected people, there is a 50-percent chance two of them will share the same birthday, and there's a 99.9 percent chance when the number is increased to 70 people.

The same principle can be used by cryptographers to find so-called collisions, in which the output of two chunks of encrypted text is the same.

Collisions, in turn, easily return the plaintext.

By collecting hundreds of gigabytes worth of HTTPS or VPN data and carefully analyzing it, the attackers are able to recover the sensitive cookie. In response to the new attack, which the researchers have dubbed Sweet32, OpenVPN developers on Tuesday released a new version of the program that actively discourages the use of 64-bit ciphers. OpenSSL maintainers, meanwhile, said in a blog post that they plan to disable Triple DES in version 1.1.0, which they expect to release on Thursday.
In versions 1.0.2 and 1.0.1, they downgraded Triple DES from the "high" to "medium," a change that increases the chances that safer ciphers are used to encrypt data traveling between servers and end users.

The precise cipher choice is made dynamically and is based on a menu of options supported by both parties. While stripping Triple DES out of all versions would be the safest course, it also would leave some people unable to browse certain HTTPS sites altogether. “A matter of good hygiene” "When you have a large installed base, it is hard to move forward in a way that will please everyone," Rich Salz, a senior architect at Akamai Technologies and a member of the OpenSSL developer team, wrote. "Leaving triple-DES in 'DEFAULT' for 1.0.x and removing it from 1.1.0 is admittedly a compromise. We hope the changes above make sense, and even if you disagree and you run a server, you can explicitly protect your users through configuration." Browser makers are also in the process of making changes that prioritize safer ciphers over Triple DES. The Sweet32 attack will be presented in October at the 23rd ACM Conference on Computer and Communications Security. While the time and data-collection requirements present a significant barrier, it works as described on sites that support Triple DES and allow long-lived HTTPS connections.

As of May, about 600 websites in the Alexa 100,000 were identified, including those mentioned at the beginning of this article. Karthikeyan Bhargavan and Gaëtan Leurent—the researchers behind Sweet32—estimate that about 1 percent of the Internet's HTTPS traffic is vulnerable. OpenSSL team member Viktor Dukhovni summed things up well in an e-mail. "We're not making a fuss about the 3DES issue, and rating it 'LOW," Dukhovni wrote. "The 3DES issue is of little practical consequence at this time.
It is just a matter of good hygiene to start saying goodbye to 3DES."