I am sure that most non-technical people, when pronouncing about encryption, think of it either as a black box which is too tough to grok, or as a simple cipher such as those used long before the twentieth century.
Very old ciphers could be relatively simple, because everything had to be done in longhand. One of the simplest is a basic substitution cipher, in which each letter of the alphabet (or, if you want to be modern, each byte) is substituted by another.
Let’s say that your password is AWESOMEHANDTHROB. You might write the alphabet along the top, and then a new re-ordered version of the alphabet based on your password below:
To encode the letter H, simply look at the letter below it, N, and so on. The obvious flaw with that is that all someone has to do to break the cipher is to analyse a chunk of encoded text for letter frequencies. As words remain at the same lengths too, a good cryptanalyst should be able to break this faster than a crossword puzzle.
Galloping through centuries of the history of encryption in a few words, increasingly sophisticated codes were devised which became increasing difficult to break.
Modern encryption does not just rely on the password or passphrase which you choose. In most cases, the method of encryption requires a key which is a fixed number of bits long. Humans are also remarkably bad at choosing and remembering truly random passwords, even when fairly short, so the first step in most methods involves ‘adding salt‘ to the password in the form of random bits to make it much more difficult to attempt a ‘dictionary attack’ (in which all possible passwords are tried, in order of the most likely).
Normally, the ‘salt’ is a random number which is concatenated onto the password. The result of that is then hashed, passing through a special one-way key generation algorithm, to produce the key to be used. So your chosen password of
4Lexi5qaIi might be turned into a 32-byte key of
C839 0F2D D518 7B89 903A 7E38 527C A902, which you are hardly likely to be able to recall in a hurry.
Before AES encryption proper can start, separate versions of the key are prepared for use in each round of the encryption itself. The details of this are given in Wikipedia and elsewhere, but for use with a 256-bit (32-byte) key, a series of operations is performed to turn those 32 bytes into 240 bytes of ‘expanded key’.
AES operates on fixed-length blocks of input ‘plain text’ (which is usually binary data), each 128 bits or 16 bytes long. For each of these blocks, it performs a series of encryption steps using parts of the expanded key.
The initial round of encryption takes the section of expanded key to be used for the step, and combines it with the input bytes using an
AddRoundKey operation shown below in diagrammatic form.
Then a sequence of four operations is performed 14 times, each with a different section of the expanded key for that round: the round key. The sequence consists of the diagrammed steps of
MixColumns, and finally
SubBytes replaces each byte with a substitute taken from a special lookup table, based on an ‘S-box‘. This is a non-linear substitution which has an elaborate mathematical basis, using an invertible affine transformation.
ShiftRows performs a cyclical rotation by shifting the bytes in each row, as shown. This ensures that columns (which are the bytes in sequence in the original input) do not encode independently, as if four separate block ciphers.
MixColumns operates on each column, applying an invertible linear transformation to them using a fixed matrix. This, combined with
ShiftRows, ensures that the statistical structure of the plaintext input is diffused throughout the encrypted output, and prevents an attacker obtaining information by analysing the frequency of encrypted bytes (as in the simple cipher at the top).
AddRoundKey is the same as in the initial round, and changes the input by combining the round key with it.
Once these have been repeated 14 times, a final round is performed, which omits the
MixColumns step, and the resulting 16 bytes is then fully encrypted output.
Although the whole process may appear very laborious and computationally complex, many modern processors have instructions which enable AES to be implemented very efficiently, thus for high speeds of encryption and decryption: this is the great advantage of being adopted by the US government as a federal standard.
Recognising the importance of ‘salting’, and the fact that those using iOS devices are unlikely to cope with entering 10-character robust passwords, Apple looked at various solutions for generating robust encryption keys for iOS devices. The one that it has chosen appears to be highly robust, as it relies on a secret key which is unique, and built into the hardware of every iOS device: the UID key.
The passcode (four or six digits) is then combined with the UID key to generate other keys used to access the device, file metadata, and file contents. Only the device itself knows its UID key. Of course if an attacker (or law enforcement agency) were able to access the UID key, then it would not take too long to run through the different possible passcodes until they hit on the right combination.
To prevent that from happening, the UID key is kept in a special cryptographic processor, the Secure Enclave. This is designed so that it is impossible to extract the UID key from it. So the only way of breaking into an iOS device is to run a cracking attempt on that device, and this has been carefully engineered to take a significant length of time. But without access to the device with its Secure Enclave, it is not practically possible.
Although the Secure Enclave is featured in A7 and later A-series processors, used in the iPhone 5s and iPad Air onwards, earlier processors still have similar function, so will also not provide their UID key to an attacker.
Apple has recognised that building any form of backdoor into these devices to enable someone to read the UID key would, sooner or later, be abused by attackers, rendering all its encryption worthless.
It is believed that some older models of iPhone could be started up from a custom boot image which bypassed PIN entry, and did enable Apple and law enforcement agencies to access the contents of locked iPhones. That is clearly not something which would be acceptable to Apple’s customers now, as it would be far too easy for an attacker to exploit.
Illustrations are by Matt Crypto, via Wikimedia Commons.