Posts Tagged ‘Cryptography’

« Older Entries

Cryptography is brittle: almost right is often equivalent to epic fail

Tuesday, May 17th, 2011

Resistance to side-channel attacks (SCA) is especially elusive. While theoretical weaknesses in the cryptographic algorithms are supposed to be prevented by choosing appropriate algorithms, choosing an algorithm that is known to be SCA-resistant does not guarantee much: the SCA-resistance is a property of implementation, not of the algorithm.

Consider Montgomery ladder. Each step in the algorithm is obviously constant-time and thus you may think that the time it takes to do a scalar multiplication of a point by number k should not leak your secrets. This reasoning seems correct until you realize that the number of steps must be constant too. It turns out that even highly-skilled OpenSSL developers can forget about that:

This paper describes a timing attack vulnerability in OpenSSL’s ladder implementation for curves over binary fields. We use this vulnerability to steal the private key of a TLS server where the server authenticates with ECDSA signatures. Using the timing of the exchanged messages, the messages themselves, and the signatures, we mount a lattice attack that recovers the private key.

Ironically, in the end it is the regular execution of the ladder that causes this side-channel vulnerability: for example, a dependency on the weight of k (that might leak from, say, a simple binary scalar multiplication method) seems much more difficult to exploit than that of the length of k that led to full key recovery here.

On the other hand, if we know that the execution time is constant, we can quite easily test. The lesson is obvious: Do not just assume properties of your implementation to be the properties of the algorithm you implement, do test them!

No Comments

Forging Canon Original Decision Data

Tuesday, November 30th, 2010

Although the image manipulation was widely used in the analog age, the digital technology made it much more convenient. To enhance the credibility of photographic evidence, many Canon DSLR cameras have the originality verification function:

Original image verification data becomes embedded in every image shot with a compatible camera. Original Data Security Utility quickly verifies the originality of an image by isolating the image from the verification data and comparing the two with utmost accuracy.

Today (2010-11-30) Dmitry Sklyarov explained how the Canon’s Original Decision Data feature works and how it can be broken. That is how he have created edited photos that successfully pass the authenticity verification.

As usual in such cases, it turned out that cryptography was used incorrectly: the original decision data (ODD, there are several different versions) is calculated by an obscure sequence of hash and HMAC operations with a secret key, which depends on the camera model and public data (e.g., BodyID stored in EXIF). Since the camera firmware can be dumped and an attacker can even run his own code on the camera processor, it is easy for the attacker to forge the ODD.

Software obfuscation and security thru obscurity can hinder an attacker for a while, but without a cryptoprocessor that can protect the secret key, there is nothing Cannon can do. Of course, it would be even better to use the public-key cryptography, so that breaking a single camera would not allow an attacker to forge images of all the cameras of the same model.

By the way, if the name of the authors seems familiar it is most likely because he is the Russian cryptanalyst who was arrested on 2001-07-16, after giving a presentation called “eBook’s Security — Theory and Practice” at the DEF CON convention in Las Vegas.

No Comments

Bringing Access-Based Cache Attacks on AES to Practice

Thursday, November 25th, 2010

Personal computers are mostly used by a single person or shared between a group of users that trust each other, in cloud computing users usually do not trust each other: the owner of one process may have a great interest in the encryption keys used by a process owned by another user. Since the OS provides separate address space for each process, it may seem that the attacker has no way to steal the key. Turns out the attack may be practical.

To understand how the attack works we need to recall how memory is accessed by a program: Before requesting data from a memory chip, processor checks whether the data was recently accessed and saved in the cache. If the data is in the local cache, it can be accessed hundred times faster than otherwise. To make the implementation easier, the cache is designed in such a way that each memory location is allowed to be cached only in few places: to check that a memory location is cached, only these few places need to be checked.

Software implementations of the AES cipher commonly employ a look-up table. Which places in this table are accessed depends on which data is encrypted and which key is used. If an attacker, by accessing memory in his address space and checking how long it takes, can deduce what parts of the look-up table were accessed, he may deduce the key.

Cache-based side-channel attacks (SCA) against AES are known for a long time, what is new is the practicality of the attack:

[Our] spy process neither needs to learn the plain- or ciphertexts involved, nor their probability distributions in order [to] recover the secret key.

We describe how besides the key also the plaintext can be recovered without knowing the ciphertexts at all

We have a fully working implementation of our attack techniques against the 128-bit AES implementation of OpenSSL 0.9.8n on Linux. It is highly efficient and is able to recover keys in realtime. More precisely, it consists of two phases: in an [observation] phase, which lasts about 2.8 seconds on our test machine, about 100 encryptions have to be monitored. Then, an offline analysis phase, lasting about 3 minutes recovers the key.

Usually, implementing a counter-measure for SCA makes implementation slower, fortunately, the new processors give us a good way to prevent the attack and improve the performance simultaneously: AES Instruction Set (an extension to the x86 instruction set architecture for microprocessors from Intel and AMD) is already used by many software packages.

No Comments

Hardware Assisted DRM

Tuesday, November 16th, 2010

Hardware and software working in tandem to create effective content protection for connected devices
Tandem Racer
There was never any doubt about a mobile device’s ability to display video, however the large screens and powerful processors of the new generation mobile devices (smartphones and tablets) offer the consumer a more compelling viewing experience than ever. Moreover, home entertainment devices (TVs, set-top boxes (STB) and DVRs) are increasingly connected to the Internet, opening up a host of new viewing options for TV viewers, outside of the cable operator’s walled garden.

These trends are disrupting the traditional relationships existing between subscribers and service providers. This so-called disintermediation is being felt in the market, with cable operators offering video services to mobile subscribers and mobile operators offering video-on-demand to TV subscribers. Content owners and studios are also modifying their approach by offering services directly to consumers, circumventing the incumbent service providers.

These changes in the market have created new content service providers who must now “prove” their ability to securely deploy premium content in order to gain the approval of the major studios. Content protection – or Digital Rights Management (DRM) as it is more commonly known – is most effective when deployed in conjunction with hardware-based security elements. Principally, the objective of the hardware assets is to hinder scalable attacks, i.e., attacks that allow distribution in the form of exploit code, allowing the service provider to achieve a level of security similar to STBs.

In particular, the hardware-based embedded security is used to protect key elements in the DRM, as follows:

Permanent key material and other permanent sensitive data, including group private keys, device keys, security management keys, metering data
This type of data can be classified as long-term, sensitive data that must be stored permanently in the device. The solution takes the form of an encrypted, integrity-protected secure storage facility. A hardware-based secure storage mechanism is based on an embedded root key that is unique per each device. In order to obtain the Root Key and access the sensitive data, the attacker must physically probe the main processor chip which often results in its destruction. In addition, any information obtained by the attacker is relevant only for that specific device. Physical probing must be repeated to access the sensitive data of another device. This endeavor is both expensive and impractical, and certainly not scalable.

Title related and short term keys (content keys, session keys)
Mobile devices are open systems that run applications from many sources, some of them untrustworthy. The main processor in a mobile device must be deemed part of the threat model since it may be executing malicious code – malware – and attempting to access the content and session keys during run time. This threat is mitigated by running the security critical code that handles these keys in a secure execution environment – a secure subsystem that is inaccessible to the main processor. This hardware-based subsystem cannot be compromised by software-based attacks.

Compressed content (plaintext content before decoding)
Compressed content is output by the DRM client that runs in a secure execution environment and is sent to a codec for decoding and rendering on the output display and audio devices. As noted above, the main processor is deemed part of the threat model, so the compressed content cannot simply be copied from the secure execution environment to the main memory to the codec. In order to secure this interface, the DRM client must be tightly integrated with the codec. The hardware-based solution is to send the compressed content in an encrypted form to the codec. The codec decrypts and then decodes the content.

Thus the combination of hardware-based security working in tandem with a software client creates a robust and effective content protection solution.

No Comments

Cryptographic pitfalls

Wednesday, October 27th, 2010

The field of cryptography is full of pitfalls. The same can be said about computer science in general, but in cryptography the pitfalls have a distinct character: you may never learn that you have fallen into one.

Let me give an example. Suppose you want to move N bytes starting at address A to the area starting at address B. Since every problem has a simple, fast and wrong solution, one can think that the problem can be solved by a simple loop that moves every byte number X from the first area to the second, where X goes from 0 below N. Once you try to use your program with overlapping areas, you will know that you have fallen into a pitfall: the copy will not look like a copy at all!

Let me now give a cryptographic example. Suppose you want to encrypt a message and decide to use the CTR mode. If you reuse the nonce (IV) for a different message, you compromise confidentiality of your messages, but you may never learn about this: the messages look as scrambled as they were with different nonces.

The confidentiality failure in this example is easy to show. For messages A and B and keystream X, the ciphertexts are A+X and B+X. If an attacker learns one message, he can calculate X and then the second message.

Not all cryptographic pitfalls are that easy to explain. Moreover, it seems that developers are not eager to fix the security problems unless there is a graphic depiction of the failure.

The padding oracle attack was published in 2002:

In many standards, e.g. SSL/TLS, IPSEC, WTLS, messages are first pre-formatted, then encrypted in CBC mode with a block cipher. Decryption needs to check if the format is valid. Validity of the format is easily leaked from communication protocols in a chosen ciphertext attack since the receiver usually sends an acknowledgment or an error message. This is a side channel.

In this paper we show various ways to perform an efficient side channel attack. We discuss potential applications, extensions to other padding schemes and various ways to fix the problem.

but it turns out that even in 2010 many developers continue to make the same mistakes over and over again:

we show that widely used web development frameworks and web sites are using encryption incorrectly in a way that allows attackers to read and modify data that should be protected. It has been known for years in the cryptography community that encryption is not authentication. If encrypted messages are not authenticated, data integrity cannot be guaranteed which makes systems vulnerable to practical and dangerous chosen-ciphertext attacks, one of them being the padding oracle attack presented by Vaudenay at EuroCrypt 2002

What is the proper way to solve all such cryptography misuses once and for all? One approach is to educate the developers, but the experience shows that this approach is not that effective as one may hope. Another approach is based on the observation that if you cannot educate everyone who will use your tools, it pays to make tools that are hard to misuse.

Consider the CBC mode of encryption. One of its main drawbacks is that the message must be padded to a multiple of the cipher block size. This does not only increase the ciphertext size, but also allows to check the integrity of the padding during decryption. In most cases the size increase is negligible, but the ability to &lquot;check&rquot; integrity gives a false sense of security. This misunderstanding leads to spectacular attacks.

Recently, NIST published an addendum that will probably do more to prevent the CBC misuses, than all the warnings that CBC does not provide authentication:

This addendum to [NIST Special Publication 800-38A] specifies three variants of CBC mode that accept any plaintext input whose bit length is greater than or equal to the block size, whether or not the length is a multiple of the block size. Unlike the padding methods discussed in [SP 800-38A], these variants avoid ciphertext expansion.

The new mode does not only save space, but the fact that there is no authentication becomes obvious: if you change a bit in the ciphertext, then some plaintext becomes gibberish, but the decryption function does not even notice.

No Comments

Encrypted Backup

Wednesday, October 6th, 2010

BlackberryThe information people store  securely on their mobile devices (e.g. passwords and PIN codes) not only needs to be stored confidentially, its availability must be protected as well. The confidentiality benefits if the data is not replicated. For example,  even if your password is weak, but an attacker has no access to data encrypted with the password, the password weakness does not assist him.

On the other hand, the availability benefits from replication: if you store the only copy of your data on a device and the device is broken, the data is no longer available. To harmonize the confidentiality and the availability can be a challenge that is easy to fail. Consider the recent case of the extremely popular BlackBerry device.

According to ElcomSoft CEO Vladimir Katalov: All data transmitted between a BlackBerry Enterprise Server and BlackBerry smartphones is encrypted with a highly secure AES or Triple DES algorithm. Unique private encryption keys are generated in a secure, two-way authenticated environment and are assigned to each BlackBerry smartphone user. Even more, to secure information stored on BlackBerry smartphones, password authentication can be made mandatory through the policies of a BlackBerry Enterprise Server (default, password authentication is limited to ten attempts, after which the smartphone’s wiped clean with all its contents erased).

Backup encryption uses AES with a 256-bit key. So far, so good. An AES key is derived from the user-supplied password, and this is where the problem arises.

In short, standard key-derivation function, PBKDF2, is used in a very strange way, to say the least.  Where Apple has used 2,000 iterations in iOS 3.x, and 10,000 iterations in iOS 4.x, BlackBerry uses only one. Another significant shortcoming is that it’s BlackBerry Desktop Software that encrypts data, not the BlackBerry device itself. This means that the data is passed from the device to the computer in a plain, unencrypted form.

There are two problems: the small iteration counter and the exporting of unencrypted data. The main purpose of PBKDF is to slow down the bruteforce attacks by using a large iteration counter and thus by using only one iteration the protection is effectively defeated.

The second problem is probably even more severe while its effect is not that obvious. The usual network security model is that the network is insecure while the endpoints are secure. Historically this was the case, but currently the security situation on the most the most commonly used desktop OS is so bad, that an antivirus is considered a must. In the modern world a security-cautious user knows that he cannot be sure who really “0wns” his desktop, and may decide to keep his the most confidential data on a mobile device.

Apparently, the BlackBerry’s backup procedure renders this strategy ineffective – an attacker who “0wns” user’s desktop gets all the mobile device secrets as well.

No Comments

Letting some air out the Tire Pressure Monitoring Systems (TPMS)

Sunday, August 22nd, 2010

Flat TireIronically when a security system contains flaws, it introduces new security problems.

Tire Pressure Monitoring Systems (TPMS) have been compulsory in new automobiles in the US since 2008. The TPMS is supposed to increase car security by reporting low tire pressure. Shortly after the plan became public, the security implications were obvious.

the people who are designing these systems are putting ”zero thought into security and privacy issues.

Now it’s possible to build intelligent improvised explosive devices (IED) capable of attacking specific targets! Or mines that will only disable vehicles with certain tires, e.g. those usually encountered on humvees, while leaving legitimate, civilian traffic alone.

Of course, the implications were obvious only to “professional paranoids”. Now, once the system becomes widely deployed, its security was evaluated is a recent research paper, excerpts of which are quoted below. And while the IED comment is meant as a joke, highway robbers are well known for making drivers pull over by puncturing their car tire.  The vulnerabilities of the TPMS show that they can virtually puncture the tire of a specific car.

This paper presents a privacy and security evaluation of wireless Tire Pressure Monitoring Systems using both laboratory experiments with isolated tire pressure sensor modules and experiments with a complete vehicle system. We show that eavesdropping is easily possible at a distance of roughly 40m from a passing vehicle. Further, reverse-engineering of the underlying protocols revealed static 32 bit identifiers and that messages can be easily triggered remotely, which raises privacy concerns as vehicles can be tracked through these identifiers. Further, current protocols do not employ authentication and vehicle implementations do not perform basic input validation, thereby allowing for remote spoofing of sensor messages. We validated this experimentally by triggering tire pressure warning messages in a moving vehicle from a customized software radio attack platform located in a nearby vehicle.

at the end of only two days of sporadic experiments involving triggering the TPMS warning on and off, we managed to crash the TPMS ECU and completely disabled the service.

We attempted to reset the system by sending good packets restarting the car, driving on the highway for hours, and unplugging the car battery. None of these endeavors were successful. Eventually, a visit to a dealership recovered the system at the cost of replacing the TPMS ECU.

No Comments

More functionality = less security

Sunday, July 11th, 2010

It’s often easier to make a complex system from ready parts. Instead of providing specific functionality, the resultingBusiness conference device does a lot more than you actually need. In so far as the system manages to do what is needed, nobody should complain about the extra functionality. However the extra functionality usually has severe consequences for the device’s level of security. An interesting example of this was presented at Hack in the Box this year.

A wireless presenter – designed to allow only a couple of functions (next/previous), easily achieved with a mouse and a keyboard – can allow someone to take over your computer while you make a presentation.

No Comments

Perils of Provisioning

Monday, July 5th, 2010

In order to securely access high-value services (such as high-definition video content or e-commerce), devices need a so-called “root of trust”—most commonly a key pair for a public-key cryptography scheme. Furthermore, the devices also need an internal root of trust for securing their internal databases; most commonly, this will be a secret key (RKEK, or root key-encryption key) unique to the device and unknown outside it.

The challenge with all of these secrets is that they have to get to the device, usually at some point during its manufacturing (or when it is activated). But to get a secret from one place to another, we need a secure channel; and the only two ways known to establish such a channel are either physical security or cryptographic security. In this case, physical security implies a secure assembly plant, which raises costs. Cryptographic security, on the other hand, requires a secret key to be shared between the sender and recipient—which then becomes a chicken-and-egg problem.

The Discretix solution to provisioning the device RKEK involves use of the digital random-bit generator (DRBG) built into CryptoCell. The DRBG is built according to NIST cryptographic standards (NIST SP800-90), and produces truly random, cryptographic-strength random bit vectors. Discretix’ provisioning tools use this DRBG on the manufacturing line in order to produce the per-device key and program it securely into the device’s non-volatile memory.

Discretix’ solution to provisioning OEM-supplied assets (such as key pairs for enabling high-value services) is more complicated. The foundation for Discretix’ solution is a 128-bit secret embedded in every CryptoCell; this secret is combined with an OEM public key in order to produce a per-OEM provisioning key. Since the secret is not itself known to OEMs, these provisioning keys can only be computed by the manufacturer of the CryptoCell-enabled chip (or by the CryptoCell device itself); since the same key is used for code signing, one OEM cannot reproduce another OEM’s key. Even more importantly, no-one else—including any eavesdroppers on communication lines, or untrustworthy assembly-plant employees—can compute these keys. These keys are then used by the OEM to encrypt and sign their secure assets; the encrypted assets are recorded in the device’s memory, and the embedded CryptoCell can verify their authenticity and decrypt them when access to the services is required.

The end result from all these mechanisms is a secure solution for provisioning a device with all the secrets it needs for high-value services.

No Comments

Side-channel attacks for Software-as-a-Service

Sunday, June 27th, 2010

Side-channel attacks (SCA) are usually associated with high-tech equipment used to monitor power consumption and electro-magnetic emanations of a smart card. Yet a web server thousands mile away can also by attacked using SCAs. As shown in a recent research paper, monitoring how much information was received and how much time it takes, allows the attacker to find out what encrypted information was received by a web browser.

With software-as-a-service becoming mainstream, more and more applications are delivered to the client through the Web. Unlike a desktop application, a web application is split into browser-side and server-side components. A subset of the application’s internal information flows are inevitably exposed on the network. We show that despite encryption, such a side-channel information leak is a realistic and serious threat to user privacy. Specifically, we found that surprisingly detailed sensitive information is being leaked out from a number of high-profile, top-of-the-line web applications in healthcare, taxation, investment and web search: an eavesdropper can infer the illnesses/medications/surgeries of the user, her family income and investment secrets, despite HTTPS protection; a stranger on the street can glean enterprise employees’ web search queries, despite WPA/WPA2 Wi-Fi encryption. More importantly, the root causes of the problem are some fundamental characteristics of web applications: stateful communication, low entropy input for better interaction, and significant traffic distinctions. As a result, the scope of the problem seems industry-wide. We further present a concrete analysis to demonstrate the challenges of mitigating such a threat, which points to the necessity of a disciplined engineering practice for side-channel mitigations in future web application developments.

No Comments

« Older Entries