We all use encryption every day, often without realising it. On-line purchases, ATM transactions, and cell phone calls are all routinely encrypted, so it is strange to think that data is frequently stored in an unencrypted manner on home and business computer systems. Data forms a very valuable and sensitive asset for a company, and the loss or theft of a PC or the hacking of the corporate network can lead to significant costs from lost revenue and commercial secrets.
Encrypted data storage shares much in common with streaming data, as both rely on complex manipulation using a key that is kept secret from a would-be attacker or adversary. The key needs to include a sufficient number of bits so that – for all practical purposes – it never repeats itself.
Unlike many schemes used for encrypting streaming data, the data storage community decided against any expansion of the encrypted data compared to the “plaintext”, even though today’s drives are produced with huge storage capacities. In this context, the term “plaintext” refers to any unencrypted data, which could be a document, video clip, photo, spreadsheet or any form of file that is stored on the system’s drive(s).
In 2010, the US National Institute of Standards and Technology (NIST) approved the XTS scheme as one of the modes of the Advanced Encryption Standard (AES). This superseded the earlier LRW mode, which suffers from security concerns. XTS includes some additions that are specifically for encrypting stored data, which is sometimes referred to as “data-at-rest.”
Considerable effort is expended on all encryption schemes to attempt to frustrate and defeat attempts to break the system. Some crypto schemes rely on obscurity of the encoding scheme, whereas AES is a published specification. The advantage of a public specification is that it is open to the wider community for peer group review. The benefit of this scrutiny is illustrated by the fact that it exposed a weakness in the LRW recommendation, which led to the introduction of the XTS specification.
An important difference between XTS and streaming data is that the encrypted data will also be dependent on the actual physical sector where it is stored. The reason for including this feature is because it must be assumed that an attacker can read and write (in an encrypted form) to all the disk locations and could modify and attempt to decrypt unused sectors. The significance of this becomes clear when you consider the wide range of data that needs to be stored. For example, uncompressed video and photos can have a substantial number of blocks of repeated data. This redundancy in the data is used by compression schemes such as JPEG and H.264, but repeated blocks could also help an attacker of the crypto scheme to estimate the encryption keys and therefore access the plaintext.
The concept of including a “tweak” addresses this attack. Here two keys are used that represent the encryption key and a tweak key, so that 128-bit AES (AES-128) requires a 128 + 128-bit key and similarly a 512-bit key is used to provide AES-256. The tweak combines with the sector address, and this is used in a combined process termed Xor-Encrypt-Xor to produce a cryptographically strong number based on the sector number and a secret key. Using this extra dimension within the process ensures that identical plaintext, using the same encryption key, will be stored as non-identical encrypted data. It also frustrates any attempt to write known data to a sector and then requesting the system to decrypt it, because the decryption will be different for every sector.
AES is a block cipher that processes data in 128-bit blocks. These blocks map efficiently into the formatted storage area of disk or solid state drives. One consideration is how to handle the final block to be encrypted, which would not normally form a completely full block. A simple addition of padding bits to fill out the 128-bit block is a possibility that is both simple and cheap to implement. The XTS scheme includes an optional feature called “ciphertext stealing”. This is where the contents of the final two blocks are combined and encrypted to obscure the data. The technique ensures that the data is not expanded, but it does introduce significant latency and additional complexity, because the system needs to detect the end of data for both encryption and decryption before it can commence the ciphertext stealing process. For these reasons, the ciphertext stealing option will not always be implemented.
The implementation of XTS-AES can be as a software solution. The advantage is that it can run on an available processor within the drive unit. It needs to be integral because it takes the sector address as information used in the tweak operation. There are two main issues that need to be considered before deciding on a software solution: will the keys be safe and will it be fast enough? The security of the keys is of prime importance, because if these are discovered by hacking the software code or reading data buses, then the whole purpose of encrypting the drive is negated. Also, data reading and writing speed could be severely limited by the processor speed of execution.
Hardware-based solutions include dedicated SoC designs or FPGA implementations. A cost-effective route is to license an XTS core from a specialist provider. As an example, Algotronix Ltd
is a crypto expert based in the UK that offers a range of AES cores, including a dedicated XTS product. The benefits of licensing IP cores are well known, as they save the user cost and the time to learn the protocol. With crypto products there are additional considerations, because the licensee gets a proven solution that is known to be correct and – very importantly – without Trojan or Backdoor malware. The core should also be designed with attacks such as differential power analysis in mind. These are where an adversary attempts to learn information about the keys by measuring glitches on the power supply lines, and a good design will minimise these transients.
The speed of operation in a hardware core can be designed to match the requirement by using techniques such as pipelining. In this way the core running in an FPGA can be optimised for, say, SATA 3 or SATA 6 or the needs of 10G Fibre Channel.
Users should select a core which also offers a low total cost of ownership (TCO). Factors affecting TCO include the initial license fee, any unit royalties, and the hardware and software engineering time to integrate the core. IP vendors tend to either specialise in FPGA designs or they supply cores for ASIC/SoC customers. The license cost differential can be huge, because the customer base for ASIC is so narrow, while there are an estimated 100,000 FPGA starts each year. In addition, some FPGA IP vendors will not charge royalties, as there is no practical way to track unit shipments of products using standard FPGA devices. A few FPGA specialists, such as Algotronix, offer a very attractive license price for ASIC/SoC users because they enjoy the benefit of high volume from the large FPGA customer base.
The IP may be supplied in netlist form or as source code. A netlist may often have a lower license fee, but comes as a predefined function that cannot be changed. This works well where the design is completely frozen at the time of licensing. In contrast, the source code option will be supplied in your choice of VHDL or Verilog, and will allow the design to be modified by the user. For example, the source code allows customers to select and evaluate variables such as encrypt, decrypt or encrypt/decrypt and key length. Also, if the initial specification for a SATA 3 compatible chip is subsequently changed by Marketing to meet the demands of SATA 6, then a source code option allows the addition of extra pipelining to match the revised specification. In contrast, these parameters are “hard coded” into the netlist prior to delivery.
Having the source code available reduces the cost and complexity of a security audit. It allows the user to confirm that no virus or Trojan code is incorporated and that it cannot be forced into unauthorised states or operations. Users also find it is easier to understand the operation of the system from the source code, which speeds up the testing and documentation of the project.
Customers who need to archive the design also prefer the source code option. The core can be targeted at an FPGA to prove the functionality, even if the final solution will be in SoC. An FPGA could form a RAID controller that encrypted the data on the fly to and from the hard drives. These disks could be lower cost units that are not self-encrypting drives, yet the data will still be secured.
The value of data stored on magnetic or solid state drives is not always appreciated until it is lost or stolen. The availability of low-cost IP cores that implement AES-128 or AES-256 opens up the possibility that all drives can have high-grade encryption as standard.
About the author
Paul Dillien established High Tech Marketing to offer marketing and sales services to the semiconductor and electronics industries. He has worked in the FPGA industry for 15 years, and is the author of “The FPGA Market” report.
Paul is a Chartered Engineer and has worked in strategic and tactical marketing roles for leading US and UK semiconductor companies and has specializations in competitive analysis and negotiation. He can be contacted at email@example.com
) was established in 1998 and has a range of advanced encryption Intellectual Property (IP) products that have been designed into storage, military, satellite, gaming and other secure applications.
Algotronix has won the prestigious Institution of Engineering & Technology (IET) Innovation Awards for Electronics and was named Emerging Technology Company of the Year Award by the National Microelectronics Institute (NMI).