With Apple's case with the FBI dominating news cycles of late and new revelations that they're determined to close their security loophole by extending encryption through to iCloud, today's new patent application from Apple for a method of performing a block cryptographic operation could be of interest to those standing behind Apple's stance on privacy. But beware; it's a technical read that only geeks could truly appreciate.
Apple's Patent Background
Cryptographic algorithms are widely used for encryption of messages, authentication, encryption signatures and identification. The well-known DES (Data Encryption Standard) has been in use for a long time, and was updated by Triple-DES, which has been replaced in many applications by the AES (Advanced Encryption Standard). AES is an approved encryption standard by the U.S. government. AES is a substitution permutation network, that is fast enough to execute in both computer software and hardware implementations, relatively easy to implement, and requires little memory space.
Of note, implementations of AES do not provide much security against an attacker recovering a secret key, if the attacker has privileged access to the system implementing the cipher. However, AES is often used in potentially insecure environments. For instance, AES could be employed in a white box environment. In a white box model, it is presumed that an attacker has total access to the system performing an encryption, including being able to observe directly a state of memory, program execution, and so on. In such a model, an encryption key can be observed in or extracted from memory, and so ways to conceal operations indicative of a secret key are important. For example, the attacker can learn the secret key of an AES software implementation by observing the execution of the key scheduling algorithm.
DRM applications are one instance where it's desired to keep the attacker from finding the secret key even though the attacker has complete control of the execution process. The security of this construction resides in the use of table lookups and masked data. The input and output mask applied to this data is never removed along the process. In this solution, there is a need for knowing the key value at the compilation time, or at least to be able to derive the tables from the original key in a secure environment.
However, this solution does not solve all the application's needs for block cipher's encryption. Indeed, the case where the key is derived through a given process and then unknown at the compilation time is not included. One typical use-case is when a program is distributed over several users and each of them has their own key. In this case, it is impossible to disseminate different code to each user from a practical point of view. Another use-case is just when generating session keys (different for each session) through a given process. Of course, in this case the key is unknown at compilation time. A last case is when it is necessary to store a plenty of keys. However, it is not reasonable to consider storing around 700 kB for each key.
Apple's Invention: Multi-Block Cryptographic Operation
Apple's invention provides a method for performing a block cryptographic operation (e.g., AES, DES, 3DES, etc.) on multiple blocks at once. That is, rather than applying a cryptographic operation function separately to each block, some embodiments apply a function that performs the cryptographic operation on multiple blocks together.
Different embodiments may apply the cryptographic operation for multiple blocks in different modes of operation (e.g., ECB, CBC, or CTR, among others). When performing decryption of multiple blocks in CBC mode, some embodiments either avoid using in-place decryption or use a buffer that holds the multiple blocks, performs ECB-style decryption, then applies the initialization vectors to the multiple blocks together to generate the output blocks. For CTR encryption or decryption, the similarity of operations (i.e., the use of the same XOR operations and table lookups from one block to the next (at least during the initial rounds) allows for the re-use of the results of such operations across the multiple blocks, without the need to recompute the results.
In addition, for use in a white box environment, some embodiments apply various different white box techniques to the multi-block cryptographic operation. For instance, some embodiments will use a first white box technique (e.g., a mask value, a linear permutation operation, etc.) on a first one of the blocks and a second white box technique on a second one of the blocks. In addition, some embodiments modify the protection on the blocks between rounds of the cryptographic operation, possibly linking the blocks together, thereby further obfuscating the data at runtime.
In addition, the source code may be obfuscated in various ways in order to provide further protection against white box attackers. For instance, some embodiments mix the different rounds of the cryptographic operation for different blocks. Rather than performing round 1 for all of the multiple blocks, then round 2 for all of the blocks, etc., some embodiments mix up the rounds by, e.g., performing several rounds for one block, then a round or two for another block, etc., so long as all the dependencies between rounds are maintained.
Apple's patent FIG. 10 noted below conceptually illustrates a simplified view of a content distribution scheme that uses block encryption and decryption operations.
For more details, see Apple's patent application 20160080143 was originally filed in Q3 2014. Considering that this is a patent application, the timing of such a product to market is unknown at this time.
Patently Apple presents a detailed summary of patent applications with associated graphics for journalistic news purposes as each such patent application is revealed by the U.S. Patent & Trade Office. Readers are cautioned that the full text of any patent application should be read in its entirety for full and accurate details. About Making Comments on our Site: Patently Apple reserves the right to post, dismiss or edit any comments. Comments are reviewed daily from 5am to 6pm MST and sporadically over the weekend.