Features of LTE include;

• An all-IP flat network architecture
• Peak download rates nearing 300 mbps and upload rates of 75 mbps
• End-to-end QoS including provisions for low-latency communications
• The ability manage fast-moving mobiles
• Support for multi-cast and broadcast streams.

With LTE, the data capabilities of the mobile device are greatly extended and the technology is likely to have a massive impact on the services available to the smartphones and tablets of the future. LTE devices will be able to support high definition streaming video, advanced enterprise applications as well as payment and banking services.

The performance and functionality requirements of these applications require a robust, high performance security foundation, rooted in the chipset of the device. Moreover, LTE is likely to accelerate the adoption of open operating systems, which in and of itself creates additional security requirements. These security requirements apply to both platform and network security, as follows:

• Assuring the system boots from valid image (secure boot)
• Authenticating new images and revoking older ones (secure software updates and software image revocation)
• Accelerating secure packet-based communication (e.g. IPSec)
• Delivering a software image in an encrypted format and storing it encrypted in the device flash memory. The image gets decrypted only once the device boots (software update encryption)
• Featuring a flexible debug policy, differentiating OEMs, devices in field  (Secure Debug)
• Securely transferring an asset to the Device or the IC (either by the OEM or the IC vendor) during the manufacturing process (provisioning)
• Applying different levels of SIM lock protection (SIM Lock)
• Protecting the IMEI from alterations

In the old days of FAT the file deletion was implemented as a replacement of the first byte in the file name by 0xE5 and marking the storage as free, as a result, it was simple to undo the deletion (undelete was part of DOS). In the modern days, recovering a deleted file is much more complicated and thus UI usually implements some kind of recycle bin to help the user think twice before deleting some important information.

While in most cases users sorry that they have mistakenly deleted something and cannot recover it, for professional paranoids it is much more important that what is deleted, cannot be recovered by an adversary.

Secure deletion may seem simple: just overwrite the information in the file with junk data. This strategy works for simple file systems (e.g., FAT), but the more advanced ones try to increase file integrity by creating a new version of the file data instead of overwriting the previous data (log-structured file systems). Even for FAT, the underlying “disk” may be a flash that relocates position of “disk sectors” for wear-leveling.

Smartphones contain a lot of confidential information and thus the new research is worth reading (PDF):

We address the problem of secure data deletion on log-structured file systems. We focus on the YAFFS file system, widely used on Android smartphones. We show that these systems provide no temporal guarantees on data deletion and that deleted data still persists for nearly 44 hours with average phone use and indefinitely if the phone is not used after the deletion. Furthermore, we show that file overwriting and encryption, methods commonly used for secure deletion on block-structured file systems, do not ensure data deletion in log-structured file systems.

We propose three mechanisms for secure deletion on log-structured file systems. Purging is a user-level mechanism that guarantees secure deletion at the cost of negligible device wear. Ballooning is a user-level mechanism that runs continuously and gives probabilistic improvements to secure deletion. Zero overwriting is a kernel-level mechanism that guarantees immediate secure deletion without device wear. We implement these mechanisms on Nexus One smartphones and show that they succeed in secure deletion and neither prohibitively reduce the longevity of the flash memory nor noticeably reduce the device’s battery lifetime. These techniques provide mobile phone users more confidence that data they delete from their phones are indeed deleted.

On the other hand, an ounce of prevention is worth a pound of cure: instead of trying to delete the confidential information, it may be wiser to not store the plain-text (i.e., non-encrypted) data at all. If all your data is encrypted, then to securely delete it, it is enough to forget the key.

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!

Cars will soon be (almost) fully automated. News on experiments with cars that drive by themselves, in different scenarios and situations, make it seem obvious that soon enough the role of the driver is to be similar to that of a pilot in a passenger jet. Many people feel some itch of discomfort with this thought; the itch of “we are not there yet”. Let us see if and why we “are not there” yet, and what we can do about it.

Experiments are performed, and at a high level they seem to work. Therefore, as it appears, we are almost there, or at least we are on the right track, functionality-wise.

If there is an aspect from which our technology is not ready, it is that of security and reliability.

If there is an aspect from which we and our technology are not ready, it is that of security and reliability. Truth be told, today we cannot design an even simpler software application without having it suffer (at least) occasional reliability glitches. We prove over and over again that we just cannot build a sophisticated application that will just work without bugs and glitches, let alone be secure. Intuitively, bugs that we can afford in IT applications, and even in GPS applications, we cannot afford in the robot that turns the steering-wheel.

Whenever I raise this concern, I am often reminded of aviation software. A passenger jet is full of code as well, and nonetheless civil aviation is considered safe. However, there are at least three reasons why this comparison does not apply. First, I cannot back it up with any figures (if anyone does have any — please post a comment), but it is intuitive that the complexity of the car steering application is to be higher than that of a passenger jet. A passenger jet is more sophisticated of an apparatus, but it seems as the number of real-time events it needs to cope with, as well as the sophistication of their circumstances, are lower. Second, as any reader of the RISKS newsgroup can easily tell, aviation software is far from perfect. It does have its glitches, including cases of shutting the engines down during flight. Fortunately, there is still a pilot on board to handle such situations manually using human knowledge and common sense. This function will not exist in a self-driving car, even if there is someone sitting at the drivers seat. The pilot is a trained individual, operating by strict regulations, sitting in the aircraft for this purpose alone. A typical car driver in a self-driving car will soon enough drift into playing with the kids, sleeping, reading, or just daydreaming, without keeping his hands and attention on the automatic wheel that seems to behave nicely for years already. Third, cars play in a more active, competitive and ever-changing market than jets, with competition that is powered by individual retail customers demanding more features on a model-by-model basis. The Boeing 747 is with us for 40 years. Software in it may have changed, but probably not as dramatically as that of a car that the user changes every half a decade with an expectation of improvement.

There is no reason to believe that when pressed by requirements and regulation, a software provider cannot do better in this respect.

Despite all that, I am not as worried as probably expected. Means for making reasonably-secure and reasonably-reliable software exist, they are just expensive. So far, we succeeded in avoiding costly secure coding methodologies because we could afford to. Our software today breaks, not because there was no way to make it less breakable, but because there was no incentive for the provider to make it so. Simply put, the software provider pays the cost of security, but does not pay the cost of insecurity, so its preference is clear. There is still no reason to believe that when pressed by customer requirements and by regulation, a software provider cannot do better in this respect. At least as much as I can see, car makers are aware of the challenge that stands in front of them.

Will car steering software be all hundred-percent safe? Obviously not. Bugs and vulnerabilities will be found, and these might cost lives, like other failures in critical equipment; failures that we usually tolerate as long as kept within reason. This is a price we have to pay for advancing the state of the art into the unknown. Nevertheless, given all that the car industry should know and understand, and given that it comprehends what needs to be done at all costs, we may just as well be on the right track.

A bit of history: The GSM encryption was introduced in 1987 and then it was disclosed and shown insecure in 1994. As time passes the attacks become better and better, but for some reason the GSMA prefer to claim that the attacks are not practical:

Over the past few years, a number of academic papers setting out, in theory, how the A5/1 algorithm could be compromised have been published. However, none to date [2009-12-30] have led to a practical attack capability being developed against A5/1 that can be used on live, commercial GSM networks.

[…] In 2007-8, a hacking group claimed to be building an attack on A5/1 by constructing a large look-up table1 of approximately 2 Terabytes – this is equivalent to the amount of data contained in a 20 kilometre high pile of books.

[…] All in all, we consider this research, which appears to be motivated in part by commercial considerations, to be a long way from being a practical attack on GSM. More broadly, A5/1 has proven to be a very effective and resilient privacy mechanism.

One may suspect that there is a conspiracy to keep encryption easy to crack, but after reading the hilarious comment about 20 km of books (a 2 TB hard drive costs about $100) one is forced to apply the Hanlon’s razor.

Yesterday (2010-12-28), at 27C3, researches have shown how to reduce the attacker’s budget down to a PC, cheap mobile phones, and open source software:

Now that GSM A5/1 encryption can be cracked in seconds, the complexity of wireless phone snooping moved to signal processing. Since GSM hops over a multitude of channels, a large chunk of radio spectrum needs to be analyzed, for example with USRPs, and decoded before storage or decoding. We demonstrate how this high bandwidth task can be achieved with cheap programmable phones.

Security thru obscurity does not hold for long: once it becomes easy to present a GSM air interface to standard GSM handset, insecurities in the handsets becomes easier to find. Another 27C3 lecture (SMS-o-Death) shows what one can learn about security of “feature phones”:

We show how we analyzed these type of phones for SMS security issues and what kind of problems to overcome in the process. We show results for the major mobile phone manufacturers in the world. Everyone of them has problems. Finally we show what kind of global scale attacks one can carry out with these kind of bugs. The attacks range from interrupting phone calls, to disconnecting people from the network, and sometimes even bricking phones remotely.

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.

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.

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.

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.