Lollipops and Apples – Entering The Crypto Age!

Introduction

Large safe, openGoogle’s Lollipop will be released next week, and security will be at the core of its changes. An important element of this is in encryption-by-default, where users will have to opt-out of encryption of their files. Apple, too, with iOS 8 have taken the same route, and users must ask: “Why didn’t it happen before this?”

Our file attributes and content types have developed with little thought on keeping things truly private, and where systems are often still viewed as stand-alone machines. We also created an Internet which is full of the same protocols that we used in the days of text terminals and mainframe computers, where users typed in commands to access data, and where there was little thought about protecting the data as it is stored, analysed and transmitted. As we are increasingly move mobile, we are now carrying around our sensitive data, that at one time was protected behind physical firewalls, and the risks to our data increases by the day.

The major tension, though, is between law enforcement and the right to privacy. The FBI currently see the status quo as a way of investigating criminals and terrorists, but can see this opportunity reducing with encryption-by-default, such as with the file encryption system used in Apple’s iOS 8. With iOS 8 and Google Lollipop there will be no electronic methods to access encryption keys from existing digital forensics toolkits, and thus the encryption method breaches current laws, which force users to reveal their encryption keys when requested by law enforcement investigators. This would mean that users may be breaching current laws in both the US and the UK. The same battle too exists with Tor, where law enforcement are scared that crime can go un-noticed, whereas privacy advocates promote the rights of privacy of using Tor.

No right to remain silent with Cryptography

In the UK, citizens have the right to silence (a Fifth Amendment Right in the US – related to the right against self-incrimination) but there is an exception to this related to encryption keys, and the failure to reveal encryption keys can often be seen as a sign that someone has something to hide, and is covered by Section 49 of RIPA. The move by Apple and Google may thus breach law as they must be able to hand-over their encryption key when required. This was highlighted in 2014 when Christopher Wilson, from Tyne and Wear was jailed when he refused to hand encrypted passwords related to investigations related to an attack on the Northumbria Police and the Serious Organised Crime Agency’s websites. He handed over 50 encrypted passwords, but none of these worked, so a judge ordered him to provide the correct one, but after failing to do this, he received a jail sentence of six months.

In 2012, Syed Hussain and three other men, were jailed for discussing an attack on a TA headquarters using a home-made bomb mounted on a remotely controlled toy car. Syed, who admitted have terrorist sympathises, was jailed for an additional four months for failing to hand-over a password for a USB stick.

The following outlines some key features in disk encryption:

The Perfect Storm

The main problem that we have with computer system security is that as computer systems have evolved we created file systems which only protect using file attributes. This works well from a corporate point of view, where we can keep compatability with previous systems, and also allow system administrators to keep full control of them. The mobile device operating system creators (mainly Google and Apple), though, have different issues to the traditional desktop operating system creators, as their devices are on-the-move, and often stolen or left behind.

As we increasingly integrate the mobile phone with our lives, especially in creating a digital shadow on the Cloud, the devices need to be more protected that our traditional desktops. Along with this, Apple and Google have complete control over their operating systems, and can implement radical changes in a way that Microsoft would have struggled with (and still keeping compatibility with an operating system released over a decade ago: Windows XP). So Apple and Google are not constrained by the past, and find their hardware platforms are whizzing along with increased processing speeds and memory capacities, in a way, again, that Microsoft would struggle with, as they have so much legacy hardware that would struggle with modern cryptography.

So Apple and Google now find themselves with a market that will quick change their mobile devices and keep up-to-date, and this do not have the long tail of devices to support. If a user wants to stick with a certain operating system, they can, but there’s a good chance that their applications won’t work. With phone manufacturers pushing new phones all the time, both Apple and Google are keen too to plug the gaps in traditional operating systems, especially related to security, and they have the perfect storm with SSD (rather than the horribly slow HDDs), and fast multi-core processors, each which now make encryption possible on a device that fits in your hand. Gone are the days when you needed a special maths chip to do complex cryptography.

Some basics

It is important to understand how disk encryption typically works, as weaknesses can be identified. Overall there is no way method that is the best for securing a system, and it basically comes down to the risk level on the data contained on it. As Figure 1 illustrates, the four main methods are: to have a passphase; store key(s) on usb drive; generate access code from a OTP (One-Time Password); or use a biometric device. These methods typically allow access to the encryption keys which are used to secure the encrypted files. On many systems the encryption keys are held on a digital certificate on the host (or on the domain controller), but these can often be opened using password cracking on the certificate. Along with this, if we encrypt the whole disk, it will be difficult to get access to the digital certificate on the host, as it is part of the encrypted system. Microsoft Bitlocker gets round this problem by having two disk partition, and where one can hold the protected encryption keys.

Slide4Figure 1: Disk encryption access methods

Increasing, though, the method of using a digital certificate is difficult to sustain, and thus the move is towards a TPM (Trusted Platform Module) which embeds the encryption keys into a chip on the device. The operating system boot process then is able to access the encryption keys, and where they are protected by one of the methods defined in Figure 1. For both Apple and Google, TPM is at the core of their approach for encryption-by-default, and where the user has control over the release and methods of security around the encryption keys. If they use a PIN number, their keys are easily found, but pass phrases make it much more difficult.

Slide7Figure 2: TPM

Public and Private Keys working in harmony

Many users, even computer science graduates, thing that we either have public or private key for our secure systems, but often the two work in harmony, and focus on what they are good at. With private key, such as AES, we have a high optimized encryption method, which is fast, especially if we have the right key. Thus most encryption that happens on the disk is private key (typically 256-bit or 128-bit AES). The protection of the key then is done by public key, and where a public key encrypts the File Encryption Key (FEK), and where it can only be decrypted by the private key (Figure 3). In this way, public key does the protection of the key, and private key is the workhorse of the reading and writing of the data. The other method that is used is to generate a key based on a passphrase, and where we add some salt to it, to make sure it is an ever changing key. Overall, though, public key encryption, such as RSA, is hardly ever used in disk encryption, as it is such as slow method. As RSA keys move toward 4,096 bits, it is become increasingly difficult to process large amount of data, in real time.

Slide8Figure 3: Protecting the FEK (File Encryption Key) with public key

From File Attributes to File Encryption

At present files are typically secured by file attributes, which are acceptable on desktop systems, especially especially ones which connect to domains, but on mobile devices it is extremely difficult to define protection levels. For Unix-type systems we have simple attributes of:

drwxr-xr-x   16 billbuchanan  staff   544B 28 Sep 19:27 mydir
-rw-r--r--     1 billbuchanan  staff   201B 16 Apr  2014 results.txt
-rw-------     1 billbuchanan  staff   210B 16 Apr  2014 run.save
-rw-r--r--     1 billbuchanan  staff   194K 11 Jul 19:04 salt.svg

where were we have r(ead), w(rite) and e(x)ecute for the owner, their group and the rest of the World. In terms of keeping things simple, this is about as good as it gets, but it is often difficult to define other rights, such as for deleting and creating a file. So NTFS defines other attributes of F (Full Access), M (Modify Access), D (Delete Access):

 perm is a permission mask and can be specified in one of two forms:
     a sequence of simple rights:
             N - no access
             F - full access
             M - modify access
             RX - read and execute access
             R - read-only access
             W - write-only access
             D - delete access  

C:\dropbox>icacls *.zip
networksims_accounts.zip NT AUTHORITY\Authenticated Users:(I)(F)
                         NT AUTHORITY\SYSTEM:(I)(F)
                         BUILTIN\Administrators:(I)(F)
                         BUILTIN\Users:(I)(F)

tables_xp_free_fast.zip NT AUTHORITY\Authenticated Users:(I)(F)
                        NT AUTHORITY\SYSTEM:(I)(F)
                        BUILTIN\Administrators:(I)(F)
                        BUILTIN\Users:(I)(F)

Successfully processed 2 files; Failed processing 0 files

And then lots of extensions on the inherited rights:

 (OI) - object inherit
 (CI) - container inherit
 (IO) - inherit only
 (NP) - don't propagate inherit
 (I) - permission inherited from parent container

So NTFS works extremely well in managing the access and rights to files on a domain, and where a domain controller defines the rights for the files at a central point. It only defines the overall “owner” as the system administrator for the complete domain, so as long as it connects to the domain, the administrator has complete rights to files. This type of approach can thus be used in any investigation, where the rights on the files can be changed to suit the investigation. On a mobile device, it would be difficult to implement such complex rights, especially as many of the systems are Linux-based, so encryption is the natural way to protect files, and where the user themselves have control over their access.

Conclusions

With data breaches rising by the day, such as with 150 million passwords cracked with the Adobe infrastructure and over 120 million credit card details skimmed for Home Depot and Target, Apple and Google feel they have to build up trust with their users in their operating system. For this they are looking at encryption-by-default, where they encrypt file data (which is now stored on flash memory), and which now may breach the laws around reveal encryption keys. At one time, investigators could extract the memory from the device, and decode its contents, but without encryption keys this will be difficult. While Google and Apple have not responded to the dilemma, there could be the opportunities for them to work with the companies to overcome of the issues, which might reduce privacy settings on their data. Unfortunately if they do reduce the security on the encrypted data, they may leave open opportunities for others to learn the methods, and compromise the whole system. In a corporate market, Microsoft BitLocker is one of the most popular methods used for complete disk encryption. With this, there is always the back-door input into the encrypted data, by storing the encryption keys within the domain controller for the company.

For our rights systems, we are moving away from complex file attributes to protect files, toward simpler methods which define that we encrypt all content by default. Our old desktops have held the industry back for so long – with their lumbering magnetic hard disks and their separation of disk storage and memory storage. For mobile devices they have electronic memory for both running programs and storage, and will typically run 100s of times faster than their mechanical and magnetic brother. So for them, encryption by default is a natural extension, and with modern crypto methods such as AES, we have finally entered a new era of computing – The Crypto Age!

We have a long tail left of legacy with computer systems, typically through slow disk systems, limited processors, and a lack of memory. This shackles are now off for mobile devices, and they are free to push forward and properly integrate security, which must be build on a core of cryptography.

For the rights system on a mobile device we might have “It’s mine!”, and that’s it. From a corporate point-of-view, this will not be acceptable, so many system developers are working on properly integrating devices into the core of the infrastructure, and encryption by-default should aid this process, and not hinder it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s