Entries Tagged "keys"

Page 6 of 15

Using Intel's SGX to Attack Itself

Researchers have demonstrated using Intel’s Software Guard Extensions to hide malware and steal cryptographic keys from inside SGX’s protected enclave:

Malware Guard Extension: Using SGX to Conceal Cache Attacks

Abstract:In modern computer systems, user processes are isolated from each other by the operating system and the hardware. Additionally, in a cloud scenario it is crucial that the hypervisor isolates tenants from other tenants that are co-located on the same physical machine. However, the hypervisor does not protect tenants against the cloud provider and thus the supplied operating system and hardware. Intel SGX provides a mechanism that addresses this scenario. It aims at protecting user-level software from attacks from other processes, the operating system, and even physical attackers.

In this paper, we demonstrate fine-grained software-based side-channel attacks from a malicious SGX enclave targeting co-located enclaves. Our attack is the first malware running on real SGX hardware, abusing SGX protection features to conceal itself. Furthermore, we demonstrate our attack both in a native environment and across multiple Docker containers. We perform a Prime+Probe cache side-channel attack on a co-located SGX enclave running an up-to-date RSA implementation that uses a constant-time multiplication primitive. The attack works although in SGX enclaves there are no timers, no large pages, no physical addresses, and no shared memory. In a semi-synchronous attack, we extract 96% of an RSA private key from a single trace. We extract the full RSA private key in an automated attack from 11 traces within 5 minutes.

News article.

Posted on March 16, 2017 at 5:54 AM • View Comments

"Proof Mode" for your Smartphone Camera

ProofMode is an app for your smartphone that adds data to the photos you take to prove that they are real and unaltered:

On the technical front, what the app is doing is automatically generating an OpenPGP key for this installed instance of the app itself, and using that to automatically sign all photos and videos at time of capture. A sha256 hash is also generated, and combined with a snapshot of all available device sensor data, such as GPS location, wifi and mobile networks, altitude, device language, hardware type, and more. This is also signed, and stored with the media. All of this happens with no noticeable impact on battery life or performance, every time the user takes a photo or video.

This doesn’t solve all the problems with fake photos, but it’s a good step in the right direction.

Posted on March 1, 2017 at 6:02 AM • View Comments

Apple's Cloud Key Vault

Ever since Ian Krstić, Apple’s Head of Security Engineering and Architecture, presented the company’s key backup technology at Black Hat 2016, people have been pointing to it as evidence that the company can create a secure backdoor for law enforcement.

It’s not. Matthew Green and Steve Bellovin have both explained why not. And the same group of us that wrote the “Keys Under Doormats” paper on why backdoors are a bad idea have also explained why Apple’s technology does not enable it to build secure backdoors for law enforcement. Michael Specter did the bulk of the writing.

The problem with Tait’s argument becomes clearer when you actually try to turn Apple’s Cloud Key Vault into an exceptional access mechanism. In that case, Apple would have to replace the HSM with one that accepts an additional message from Apple or the FBI­—or an agency from any of the 100+ countries where Apple sells iPhones­—saying “OK, decrypt,” as well as the user’s password. In order to do this securely, these messages would have to be cryptographically signed with a second set of keys, which would then have to be used as often as law enforcement access is required. Any exceptional access scheme made from this system would have to have an additional set of keys to ensure authorized use of the law enforcement access credentials.

Managing access by a hundred-plus countries is impractical due to mutual mistrust, so Apple would be stuck with keeping a second signing key (or database of second signing keys) for signing these messages that must be accessed for each and every law enforcement agency. This puts us back at the situation where Apple needs to protect another repeatedly-used, high-value public key infrastructure: an equivalent situation to what has already resulted in the theft of Bitcoin wallets, RealTek’s code signing keys, and Certificate Authority failures, among many other disasters.

Repeated access of private keys drastically increases their probability of theft, loss, or inappropriate use. Apple’s Cloud Key Vault does not have any Apple-owned private key, and therefore does not indicate that a secure solution to this problem actually exists.

It is worth noting that the exceptional access schemes one can create from Apple’s CKV (like the one outlined above) inherently entails the precise issues we warned about in our previous essay on the danger signs for recognizing flawed exceptional access systems. Additionally, the Risks of Key Escrow and Keys Under Doormats papers describe further technical and nontechnical issues with exceptional access schemes that must be addressed. Among the nontechnical hurdles would be the requirement, for example, that Apple run a large legal office to confirm that requests for access from the government of Uzbekistan actually involved a device that was located in that country, and that the request was consistent with both US law and Uzbek law.

My colleagues and I do not argue that the technical community doesn’t know how to store high-value encryption keys­—to the contrary that’s the whole point of an HSM. Rather, we assert that holding on to keys in a safe way such that any other party (i.e. law enforcement or Apple itself) can also access them repeatedly without high potential for catastrophic loss is impossible with today’s technology, and that any scheme running into fundamental sociotechnical challenges such as jurisdiction must be evaluated honestly before any technical implementation is considered.

Posted on September 8, 2016 at 8:00 AM • View Comments

Collision Attacks Against 64-Bit Block Ciphers

We’ve long known that 64 bits is too small for a block cipher these days. That’s why new block ciphers like AES have 128-bit, or larger, block sizes. The insecurity of the smaller block is nicely illustrated by a new attack called “Sweet32.” It exploits the ability to find block collisions in Internet protocols to decrypt some traffic, even though the attackers never learn the key.

Paper here. Matthew Green has a nice explanation of the attack. And some news articles. Hacker News thread.

Posted on August 26, 2016 at 2:19 PM • View Comments

Hackers Stealing Cars

We’re seeing car thefts in the wild accomplished through hacking:

Houston police have arrested two men for a string of high-tech thefts of trucks and SUVs in the Houston area. The Houston Chronicle reports that Michael Armando Arce and Jesse Irvin Zelaya were charged on August 4th, and are believed to be responsible for more than 100 auto thefts. Police said Arce and Zelaya were shuttling the stolen vehicles across the Mexican border.

[…]

The July video shows the thief connecting a laptop to the Jeep before driving away in it. A Fiat-Chrysler spokesman told ABC News that the thieves used software intended to be used by dealers and locksmiths to reprogram the vehicle’s keyless entry and ignition system.

Posted on August 11, 2016 at 6:32 AM • View Comments

BlackBerry's Global Encryption Key

Last week, there was a big news story about the BlackBerry encryption key. The news was that all BlackBerry devices share a global encryption key, and that the Canadian RCMP has a copy of it. Stupid design, certainly, but it’s not news. As the Register points out, this has been repeatedly reported on since 2010.

And note that this only holds for individual users. If your organization uses a BlackBerry Enterprise Server (BES), you have your own unique key.

Posted on April 25, 2016 at 5:54 AM • View Comments

CONIKS

CONIKS is an new easy-to-use transparent key-management system:

CONIKS is a key management system for end users capable of integration in end-to-end secure communication services. The main idea is that users should not have to worry about managing encryption keys when they want to communicate securely, but they also should not have to trust their secure communication service providers to act in their interest.

Here’s the academic paper. And here’s a good discussion of the protocol and how it works. This is the problem they’re trying to solve:

One of the main challenges to building usable end-to-end encrypted communication tools is key management. Services such as Apple’s iMessage have made encrypted communication available to the masses with an excellent user experience because Apple manages a directory of public keys in a centralized server on behalf of their users. But this also means users have to trust that Apple’s key server won’t be compromised or compelled by hackers or nation-state actors to insert spurious keys to intercept and manipulate users’ encrypted messages. The alternative, and more secure, approach is to have the service provider delegate key management to the users so they aren’t vulnerable to a compromised centralized key server. This is how Google’s End-To-End works right now. But decentralized key management means users must “manually” verify each other’s keys to be sure that the keys they see for one another are valid, a process that several studies have shown to be cumbersome and error-prone for the vast majority of users. So users must make the choice between strong security and great usability.

And this is CONIKS:

In CONIKS, communication service providers (e.g. Google, Apple) run centralized key servers so that users don’t have to worry about encryption keys, but the main difference is CONIKS key servers store the public keys in a tamper-evident directory that is publicly auditable yet privacy-preserving. On a regular basis, CONIKS key servers publish directory summaries, which allow users in the system to verify they are seeing consistent information. To achieve this transparent key management, CONIKS uses various cryptographic mechanisms that leave undeniable evidence if any malicious outsider or insider were to tamper with any key in the directory and present different parties different views of the directory. These consistency checks can be automated and built into the communication apps to minimize user involvement.

Posted on April 6, 2016 at 10:27 AM • View Comments

Companies Handing Source Code Over to Governments

ZDNet has an article on US government pressure on software companies to hand over copies of their source code. There’s no details because no one is talking on the record, but I also believe that this is happening.

When asked, a spokesperson for the Justice Dept. acknowledged that the department has demanded source code and private encryption keys before.

These orders would probably come from the FISA Court:

These orders are so highly classified that simply acknowledging an order’s existence is illegal, even a company’s chief executive or members of the board may not be told. Only those who are necessary to execute the order would know, and would be subject to the same secrecy provisions.

Given that Federighi heads the division, it would be almost impossible to keep from him the existence of a FISA order demanding the company’s source code.

It would not be the first time that the US government has reportedly used proprietary code and technology from American companies to further its surveillance efforts.

Top secret NSA documents leaked by whistleblower Edward Snowden, reported in German magazine Der Spiegel in late-2013, have suggested some hardware and software makers were compelled to hand over source code to assist in government surveillance.

The NSA’s catalog of implants and software backdoors suggest that some companies, including Dell, Huawei, and Juniper—which was publicly linked to an “unauthorized” backdoor—had their servers and firewall products targeted and attacked through various exploits. Other exploits were able to infiltrate firmware of hard drives manufactured by Western Digital, Seagate, Maxtor, and Samsung.

Last year, antivirus maker and security firm Kaspersky later found evidence that the NSA had obtained source code from a number of prominent hard drive makers—a claim the NSA denied—to quietly install software used to eavesdrop on the majority of the world’s computers.

“There is zero chance that someone could rewrite the [hard drive] operating system using public information,” said one of the researchers.

The problem is, of course, is that any company forced by the US to hand over their source code would also be forbidden from talking about it.

It’s the sort of thing China does:

For most computing and networking equipment, the chart says, source code must be turned over to Chinese officials. But many foreign companies would be unwilling to disclose code because of concerns about intellectual property, security and, in some cases, United States export law.

The chart also calls for companies that want to sell to banks to set up research and development centers in China, obtain permits for workers servicing technology equipment and build “ports” to allow Chinese officials to manage and monitor data processed by their hardware.

The draft antiterrorism law pushes even further, calling for companies to store all data related to Chinese users on servers in China, create methods for monitoring content for terror threats and provide keys to encryption to public security authorities.

Slashdot thread.

Posted on March 18, 2016 at 11:27 AM • View Comments

1 … 4 5 6 7 8 … 15

Sidebar photo of Bruce Schneier by Joe MacInnis.