Data may be communicated over a channel (a data communication channel that includes one or multiple buses of a server, for example), which may be unreliable. For example, a given channel may be relatively noisy and introduce errors in bits of data, which are communicated over the channel. To communicate data over such a channel reliably, forward error correction encoding may be applied to the data at the transmission end of the channel; and at the receiving end of the channel, the data may be decoded for purposes of detecting any errors in the data as well as possibly correcting these errors. One type of forward error correction encoding uses error correction codes (ECCs) that are appended to the data and contain parity information.
Data to be communicated across a given communication channel may be encrypted for purposes of securing the data against unauthorized access. As an example, the encryption (applied at the transmitting end of the channel) and decryption (applied at the receiving end of the channel) may follow the Advanced Encryption Standard (AES) ciphers that are described in Federal Information Processing Standards (FIPS) Publication 197 (Nov. 26, 2001).
For purposes of fulfilling demands for critical low latency data access, a modern computer system (a service system, a super computer cluster or a data center, as examples) may have an in-memory database, as compared to older databases that primarily rely on mass storage devices. In general, the computer system may use measures to enhance the reliability, availability and serviceability (RAS) of this in-memory database. For example, the computer system may employ encryption and decryption, to protect the in-memory data. At the same time, the computer system may use error correction encoding and decoding to accommodate hard and soft memory errors and avoid costly down time.
In general, in accordance with example implementations, the data stored in the computer system's memory may be both encrypted and error correction encoded; and when the data is retrieved from the memory (for application processing, for example) the data may be decrypted and error decoded. In the following discussion, unencrypted, or decrypted, data is referred to as “plain text data,” and encrypted data is referred to as “cipher text data.” In general, a “cipher” is an algorithm that is applied for purposes of encrypting plain text data to produce cipher text or decrypting cipher text data to produce plain text data.
One potential way to encrypt and error encode data is to first encrypt plain text data to produce cipher text data and subsequently, perform error correction encoding on the cipher text data to produce encoded, cipher text data. This technique may, however, publically expose some parts of the error correction redundancy, which presents security concerns. Another way to encrypt and error encode data is to first perform error correction encoding on the plain text data to produce encoded plain text data and then perform encryption on the encoded plain text data to produce encoded, cipher text data. This technique may, however, present challenges when the encryption has a diffusion transformation because encryption diffusions may propagate errors (errors in noisy data, for example) to the extent that the error correction decoding may be unable to handle the relatively large number of errors.
Techniques and systems are disclosed herein that 1). perform joint encrypting and error correction encoding of plain text data to produced encoded cipher text data; and 2.) perform joint decryption and error correction decoding of the encoded cipher text data back into the decoded, plain text data. Among potential advantages of performing the error and encryption operations jointly, error correction redundancy is not exposed and the operations are less sensitive to noisy data. More specifically, systems and techniques are disclosed herein, which embed, or interleave, the encryption and error correction encoding; and also interleave the decryption and the error correction decoding.
Referring to
It is noted that the engine 150 is one of many potential entities that may perform cryptography and error correction operations, in accordance with an example implementation. The engine 150 may, as examples, be formed from hardware, hardwired logic, a processing unit that executes machine executable instructions (or “software”), or a combination of one or more of these components, depending on the particular implementation. Moreover, another software or hardware entity may perform the cryptography and error correction operations that are disclosed herein, in accordance with further example implementations.
As examples, the physical machine 100 may be a desktop computer, a laptop, a tablet, a client, a server, a smart phone, and so forth, depending on the particular implementation. Moreover, although
In general, the physical machine 100 is an actual machine that is made up of actual hardware 170, such as the memory controller 140, the memory 160, and actual machine executable instructions (or “software”) 180. As depicted in
The memory 160 represents non-transitory storage for the physical machine 100 and may be, as examples, semiconductor device-based storage (a memory formed from dynamic random access (DRAM) devices, for example); memristor device-based storage; optical storage; non-volatile memory devices; volatile memory devices or a combination of one or more of these features, depending on the particular implementation. In general, the machine executable instructions 180, when executed by the CPU(s) 120 may form various software components for the physical machine 100, such as (as examples), applications 190, an operating system 196 and operating system drivers 194. The instructions 180, in general, may be at least temporarily stored in a memory, such as the memory 160, for purposes of execution.
In accordance with example implementations, the memory 160 may store data (in encrypted and error correction encoded form) for an in-memory data base; and the execution of the machine executable instructions 180 may generate read and write requests, which are handled by the memory controller(s) (such as memory controller 140) of the physical machine 100 for purposes of storing data in and retrieving data from the memory 160.
In accordance with example implementations, the engine 150 may perform a technique 200 that is depicted in
The engine 150 may perform a technique 300 that is depicted in
For the following example implementations, the engine 150 applies encryption and decryption ciphers, which are modified versions (as further described herein) of the cryptography ciphers that are described in the Advanced Encryption Standard (AES) that is published in (FIPS) Publication 197 (Nov. 26, 2001) for purposes of interleaving error correction encoding and decoding with the ciphers.
The encryption cipher 404 includes an initial round 41, which processes plaintext data 406. As further described herein, the plaintext data 406 may have a predetermined block size, such that encryption ciphers similar to the one depicted in
In general, the initial round 411 applied an AddRoundKey transformation, which involves exclusive ORing the plain text 406 data block and the main cipher key 402. The resulting data is sequentially processed in the n−1 intermediate rounds 412. Each intermediate round 412 includes four transformations: a SubBytes transformation, a ShiftRows transformation, a MixColumn transformation and an AddRoundKey transformation, which successively process the data in the order depicted in
The SubBytes transformation is an operation for executing a non-linear conversion by dividing the received data. The ShiftRows transformation is an operation that rearranges the data block on a byte basis. The MixColumn transformation is an operation that diffuses the data. The MixColumn transformation divides the data block into sub blocks and performs a matrix conversion on each of the sub blocks. The AddRoundKey transformation exclusively ORs the data with the expanded cipher key.
The final round 416 provides cipher text data 430, i.e., the end product of the encryption cipher 404. Similar to the intermediate rounds 412, the last round 416 has the SubBytes, ShiftRows and AddRoundKey transformations, which process the data in the order that is depicted in
The decryption cipher 440 converts the cipher text data 430 into the plaintext data 406 beginning with an initial round 454 and ending with a final round 460, in the order depicted in
More specifically, as depicted in
Each intermediate round 456 includes four transformations: InvShiftRows, InvSubBytes, AddRoundkey and InvMixColumns, which are successively applied in this order, as depicted in
In accordance with example implementations, the error correction encoding/decoding by the engine 150 (see
As a more specific example, in accordance with example implementations, the engine 150 uses an encryption cipher 500 that is depicted
More specifically, similar to the final round 416, the final round 512 contains the SubBytes, ShiftRows and AddRoundKey transformations. Unlike the final round 416, the final round 512 includes an ECC encoding component. In this manner, ECC encoding 570 is applied across the final rounds 512 before the SubBytes transformations of the final round 512 to produce ECC parity data 571 that is indicative of ECC parity codewords. Due to the ECC encoding 570, the encryption process 500 produces cipher text with encrypted ECC data, as indicated at reference numeral 590.
Thus, the encryption/ECC encoding in accordance with example implementations, decomposes the AES encryption into several processing sections that operate on different blocks of the plain text data 510 and adds an ECC encoding in the last round 516 of each of these processing sections before the SubBytes, RowShift and AddRoundKey transformations. The SubBytes, RowShift and AddRoundKey transformations do not cause error propagation issues for the substituted-shifted-masked ECC codewords, because these transformations do not diffuse the data (like the MixColumn transformation, for example), and as such the transformations do not change any error weight or total error numbers that may be present in the data due to, for example, a noisy channel.
In accordance with example implementations, the encrypted ECC parity data has an inner mark and an outer mask by exclusive ORing (as depicted at reference numeral 583) the inner mask (generated from a third long cipher key 560) with the ECC parity data 571 and then applying the outer mask. More specifically, the inner mask is introduced by the processing of the third long cipher key 560, though successive rounds 580 and 582 as depicted in
The third long cipher key 560 (Cipher key 1) allows arbitrary SubBytes mapping. This feature allows customization of the engine 150 for various customers, in accordance with example implementations. The third cipher key 560 may be changed/programmed using a basic input/output operating system (BIOS) of the physical machine 100, for example.
More specifically, the round 601 is similar to the round 456, except that the ECC decoding 670 is applied across the rounds using ECC parity data 671. Thus, for the decryption, the InvRoundKey, InvRowShift and InvSubBytes transformations are applied to unmask, vice shift and vice substitute back to the ECC codewords, respectively. The decryption is temporarily suspended in the round 601 so that the ECC decoding 670 may be applied to illuminate error patterns and deliver an error-free intermediate cipher text for the rest of the decryption process 600.
As depicted in
The inverse process uses the non-linear polynomial interpolation over the large Galois Field with information seeds from the hash function for the second cipher key. Depending on the round as well as the bytes that are incorporated into the transformation, the second cipher key may have the ultra-long length overpassing the current AES cipher length of 128 bits, 192 bits, 256 bits. The brutal force attack, statistical attack and differential and linear attacks are computationally unfeasible.
The solution extends the security level by introducing the third manufacture long cipher key 560 into the SubBytes transformation to perform arbitrary SubBytes mapping. This feature allows customization of the engine 150 for various customers, in accordance with example implementations. The key may be changed using firmware and the basic input/output operating system (BIOS) to send a command to change the decryption engine, which may destroy the data retrieval without performing an expensive full data clear up.
Other implementations are contemplated, which are within the scope of the appended claims. For example, as described herein, in accordance with example implementations, the error correction encoding 570 (see
While the present techniques have been described with respect to a limited number of embodiments, those skilled in the art, having the benefit of this disclosure, will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of the present techniques.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2014/013819 | 1/30/2014 | WO | 00 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2015/116097 | 8/6/2015 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
7219237 | Trimberger | May 2007 | B1 |
7392404 | Montgomery | Jun 2008 | B2 |
7966488 | Apostolopoulos | Jun 2011 | B2 |
8045584 | Apostolopoulos | Oct 2011 | B2 |
8341429 | Buckingham et al. | Dec 2012 | B2 |
9104610 | Weingarten | Aug 2015 | B2 |
9417951 | Adikari | Aug 2016 | B2 |
9742438 | Adikari | Aug 2017 | B2 |
20030012372 | Cheng | Jan 2003 | A1 |
20040123132 | Montgomery | Jun 2004 | A1 |
20060002550 | Campagna et al. | Jan 2006 | A1 |
20070036353 | Reznik et al. | Feb 2007 | A1 |
20080192928 | Yu et al. | Aug 2008 | A1 |
20090041236 | Gligoroski | Feb 2009 | A1 |
20100202608 | Furuhashi | Aug 2010 | A1 |
20100266122 | Suzaki et al. | Oct 2010 | A1 |
20110225432 | Trichina | Sep 2011 | A1 |
20130051556 | Myung | Feb 2013 | A1 |
20130142329 | Bell et al. | Jun 2013 | A1 |
20150178146 | Adikari | Jun 2015 | A1 |
20160344409 | Adikari | Nov 2016 | A1 |
Entry |
---|
Adamo, O.B., “Joint Schemes for Physical Layer Security and Error Correction,” (Research Paper), Diss. University of North Texas, Aug. 2011, 93 pages, available at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.469.7910&rep=rep1&type=pdf. |
Cam, H. et al., “A Combined Encryption and Error Correction Scheme: AES-Turbo,” Journal of Electrical & Electronics Engineering 1, 2009, pp, 861-866, available at http://ee.istanbul.edu.tr/eng/jeee/main/pages/issues/is91/91012.pdf. |
Gupta, C.P, et al., “Joint AES Encryption and LDPC Coding,” International Journal of Scientific & Engineering Research, vol. 4, Issue 7, Jul. 2013, 4 pages, available at http://www.ijser.org/researchpaper%5CJoint-AES-Encryption-and-LDPC-Coding.pdf. |
International Search Report & Written Opinion received in PCT Application No. PCT/US2014/013819, dated Sep. 25, 2014, 13 pages. |
Kak, S.C. et al., “Joint Encryption and Error-Correction Coding,” (Research Paper), 1983 IEEE Symposium on Security and Privacy, 1983, 2 pages, available at http://dl.acm.org/citation.cfm?id=830514&CFID=254522307&CFTOKEN=35529530. |
Mao, Q. et al., “Joint Error Correction and Encryption Scheme Based on Turbo Codes,” (Research Paper), Intelligence Information Processing and Trusted Computing (IPTC), 2010 International Symposium on, IEEE, Oct. 28-29, 2010, pp. 503-506, available at http://longjisun.yolasite.com/resources/Joint%20Error%20Correction%20and%20Encryption%20Scheme%20Based%20on%. |
Chetan N. Mathur, “A Mathematical Framework for Combining Error Correction and Encryption,” Apr. 10, 2006, 86 pages <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.323.8622&rep=rep1&type=pdf>. |
Christopher Jason Peikert, “Cryptographic Error Correction,” Jul. 2006, 71 pages <https://pdfs.semanticscholar.org/7a2c/ae4a8dd92d1871ab6a703372342f228ce53a.pdf>. |
Henk van Tilborg, “Error-correcting codes and Cryptography,” May 11-12, 2011, 45 pages <http://www.win.tue.nl/cccc/cbc/slides/Henk-van-Tilborg.pdf>. |
Mathur et al., “High Diffusion Cipher: Encryption and Error Correction in a Single Cryptographic Primitive,” Jun. 2006, In ACNS, vol. 3989, pp. 309-324, <http://personal.stevens.edu/˜ksubbala/Publications/cnm-kn-kps-acns.pdf>. |
Number | Date | Country | |
---|---|---|---|
20160344428 A1 | Nov 2016 | US |