however, their focus was on achieving high throughput designs and therefore a copro- cessor at the protocol level that addresses the issue of secure key management has yet to be published. In this chapter, this problem will be addressed and a coprocessor for the acceleration of the TLS protocol will be introduced. The architecture will focus on the secure management and generation of secret key data.
7.2
Designing a Secure Coprocessor
Many embedded systems have different requirements, in terms of physical security of the device, than that of a personal computer or other large system that operates in a fixed location. Embedded devices, such as smartcards and keyfobs, are not usually kept in secure locations; therefore, an attacker has physical access to them. This gives an attacker more options in terms of the techniques that can be used to retrieve secret information from the device. Power consumption, electromagnetic radiation, and the time it takes the device to perform different operations can all be used to infer what data the device is processing at a given time.
The most valuable data in a cryptographic system, to an attacker, are the secret keys stored in the device. In the case of the TLS protocol, these secret keys are used to authenticate the device during the handshake protocol and to encrypt data in the record protocol. With access to these keys, an attacker can encrypt and decrypt data, forge digital signatures, or initiate connections on the network as if they were a legitimate user. The extent to which the system is compromised is then determined by the lifetime of the secret keys. It is feasible in many systems to have the private keys refreshed regularly; although this does degrade the performance, as a TLS handshake would have to be performed for each refresh. The system is then only compromised for the amount of time that the current keys are active, however, the attacker may then simply attempt the attack again. It is therefore advantageous to design a system that makes it difficult for an attacker to retrieve the secret keys in a timeframe shorter than that in which they are refreshed.
If a GPP is used to perform cryptographic functions in an embedded device, the private keys are usually stored in ROM or RAM. However, for the GPP to operate on these keys it must transfer them to its working memory. In many applications this working memory is a mixture of a small amount of registers internal to the processor and a larger memory bank located externally to the GPP device in the form of an SRAM or Double Data Rate (DDR) RAM module. This is a common setup in FPGA based systems where the internal memory of the FPGA is limited and mainly designed
7.2 Designing a Secure Coprocessor
to serve as small block RAM elements for custom logic functions. If memory internal to the FPGA is used to store the keys, they are vulnerable to software based attacks. If external memory is used, an attacker can simply read off the secret keys as they are transferred over an external bus. There are two solutions to this problem; all data sent over the bus to the external memory is encrypted or the keys are kept internal to the GPP. Encrypting all the data that is sent to external memory has an impact on performance for all operations that the device performs. This method also fails if an attacker develops the ability to run his own code on the device as it would be a simple task to recover the secret keys. A more secure solution is to isolate the keys from the GPP in a secure section of the chip, such as that proposed by Gaspar et al. in [40]. In this setup, if an attacker gains the ability to run code on the GPP, they will still not have access to the private keys. This limits the attacker’s options of retrieving the private keys to performing side channel attacks or physically tampering with the device.
In order to provide a methodology for designing a secure coprocessor, several as- sumptions as to the level of access an attacker has to the device must be made.
1. An attacker has the ability to execute their own software on the GPP.
2. An attacker has physical access to the device itself. This would include how the device is powered and also any external connections to the device.
3. An attacker has full control over what data can be sent to the cryptographic coprocessor.
To fully protect a device against an attacker is nearly an impossible task. The cost of manufacturing such a device would also be prohibitively expensive. Making a device sufficiently secure involves ensuring that the financial cost and computing power required to retrieve the private keys makes it infeasible and also economically unprofitable to an attacker.
The design presented in this thesis attempts to provide security against an attacker in several ways:
1. The private keys and nonces should be isolated from the GPP. Under no circum- stances should an attacker be able to retrieve the keys over the interface between the GPP and coprocessor.
2. At an algorithmic level the device should be protected against simple power anal- ysis and differential power analysis attacks.