- Email: [email protected]
I2CSec: A secure serial Chip-to-Chip communication protocol
Journal of Systems Architecture 57 (2011) 206–213
Contents lists available at ScienceDirect
Journal of Systems Architecture journal homepage: www.elsevier.com/locate/sysarc
I2CSec: A secure serial Chip-to-Chip communication protocol Jesús Lázaro ⇑, Armando Astarloa, Aitzol Zuloaga, Unai Bidarte, Jaime Jiménez University of the Basque Country, Department of Electronics and Telecommunications Alameda Urquijo s/n, Bilbao, Spain
a r t i c l e
i n f o
Article history: Received 4 May 2010 Received in revised form 21 October 2010 Accepted 10 December 2010 Available online 30 December 2010 Keywords: FPGA I2C Communication security AES-GCM
a b s t r a c t This paper presents a secured I2C (Inter-Integrated Circuit) protocol for Chip-to-Chip communications. The well known AES-GCM cryptographic and authentication algorithm is used to secure this low speed serial communication protocol. This securization allows the use of this standard into applications where security is an issue and the computation resources are constrained. Both the hardware architecture and the protocol are presented. The implementation of the I2CSec presented in the paper has been optimized for FPGA devices. Ó 2010 Elsevier B.V. All rights reserved.
1. Introduction This paper presents a basic I2C network that can be secured. This kind of low speed networks are used to control a great variety of peripherals in embedded systems. These embedded systems are present in a great variety of industrial applications due to its simplicity and availability. One problem that arises when using this kind of networks is the secrecy and privacy of the system. In some critical control applications, knowing that data is coming from the sensor and not from a malicious user is critical. The approach presented in this paper, fulfills this security requirements while, at the same time, remains within the price constrains of an embedded system. The proposed implementation assumes that the slave or master device (and configuration bitstream) is not tampered with, in other words, it is only focused in securing the communications. The cryptographic algorithms computation requirements are so high for a conventional embedded processor device, that most of its computation capacity would be needed if that computation was performed by software. For many embedded systems, this situation is not affordable [1]. In order to deal with this drawback, processors most commonly used for industrial applications such as ColdFire, have embedded cryptographic cores (crypto-cores) in the same device [2]. Using this approach, the frame encryption and decryption is performed by hardware, freeing the main processor core from this task. The main drawback of this approach is the limited flexibility that it shows. These embedded processors are ASIC technology. Thus, ⇑ Corresponding author. E-mail addresses: [email protected] (J. Lázaro), [email protected] (A. Astarloa), [email protected] (A. Zuloaga), [email protected] (U. Bidarte), [email protected] (J. Jiménez). 1383-7621/$ - see front matter Ó 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.sysarc.2010.12.001
the crypto-core is fixed on terms of algorithm implementation and interfaces; both for the software interface and for the communication media controller peripheral or core. Besides, the ASIC processor-based solution, the industry is massively adopting the core-based design methodology for system integration using Field Programmable Gate Arrays (FPGA), which leads to the appearance of the System-on-Programmable-Chip (SoPC) platforms [3]. Taking into account the fact that FPGAs do not incur in non-recurring engineering charges due to their reconfigurable nature, the number and diversity of the available IP cores for digital systems composition has heavily increased [4,5]. The SoPCs are very flexible in different ways: number and type of IP cores and processors, bus architecture, hardware and software co-processing, etc. This flexibility allows very short time-to-market and facilitates custom device design for every industry and application. The SoPC technology faces the secure communication paradigm with the maximum flexibility: depending on the application, different crypto-cores and communication media controller cores can be included in the FPGA device. For the secure communication section of the SoPC, the designer is in charge of finding the best FPGA resource occupation-data throughput trade-off and the optimum IP license cost as well. Typically, the technology for the embedded systems for this market has been dominated by the microcontrollers. However, nowadays, the computational power and flexibility that reconfigurable platforms offer are closer to this market. The main FPGA vendors, Xilinx and Altera, offer low-cost devices oriented to the consumer market. The actual options hardly justify the high cost of a custom ASIC processor-based approach for medium sized productions. In fact, some sectors have adopted the core-based design methodology for system integration using FPGAs [6]. This design flow simplifies and speeds-up the design of complex systems
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
which allows very short time-to-market and facilitates custom device design for every industry and application. Chip-to-Chip communication links are present in most of the digital systems. SPI or I2C standards are only an example and their use is being extended to security sensitive applications like sensors connections, RFID, biometric devices, etc. These links can benefit of FPGAs in order to secure the communication. Target applications of this technology are located in secure conscious environments for example securization of sensor to processor communications in industrial plants. When domotic applications want to increase they capabilities by including intrusion detection, they greatly benefit from a secured communications scheme. It must be noted that the proposed algorithm not only protects against eavesdropping but it also guarantees that the information is received from a trusted source. 2. Low speed communications security approaches There are two main areas in the low speed secured communications. One of them are wireless communications and the other industrial control like SCADA. The algorithm that we propose is suited for industrial control, specially because I2C is a very common communication standard between microcontrollers and sensors. Because our approach is so highly related to industrial control, we will begin by SCADA systems. SCADA stands for supervisory control and data acquisition. The term SCADA usually refers to centralized systems which monitor and control entire sites, or complexes of systems spread out over large areas. SCADA may control highly sensitive processes, so security is an issue [7]. In the past, SCADA systems where proprietary and where restricted to the site they where controlling. This assumed that any attacker had to gain physical access to the facility and that he had to had very specialize knowledge. In the past years, SCADA system are changing from proprietary to open source and from isolated to Internet controlled systems. This means that they are far more vulnerable and that security measures are compulsory. Specially these measures are focused in the Internet access part (DNP3 [8], RTAP [9], IF-MAP [10], Realflex [11]). But one question arises, was the original security assumption correct? Most onsite communications are not IP, they are field communications using standards such as Modbus [12], which do not have security concerns. This means that no matter how many security layers we put on our Internet connections, an intruder could bypass all of them just by gaining physical access. Another different scenario are Wireless sensor networks (WSN) [13]. In this scenario, the physical security of the sensors is compromised so steps must be taken to ensure security, both by authentication (knowing that the sensor is really what we thing) and by encryption (making our conversations secret). There are some particularities in WSN, first of all the resources, both energy and computational. Secondly deployment may not be controlled, for example they may be air-dropped. Examples of security aware protocols include TinySec [14], MiniSec [15], SPINS [16], etc. The proposed protocol fills a gap between both systems. It is focused on wired systems that do have power to spare but not processing power. The placement is definitively controlled but physical security is not guaranteed. This gap is also of interest for domotic applications, Lonworks [17] provides basic authentication scheme while KNX [18] has several security proposals such as EIBSec [19]. 3. I2C The I2C-bus [20] is a de facto world standard that is now implemented in over 1000 different ICs manufactured by more than 50
207
companies. Two wires, serial data (SDA) and serial clock (SCL), carry information between the devices connected to the bus. Each device is recognized by a unique address (whether it is a microcontroller, LCD driver, memory or keyboard interface) and can operate as either a transmitter or receiver, depending on the function of the device. Generation of clock signals on the I2C-bus is always the responsibility of master devices; each master generates its own clock signals when transferring data on the bus. All transactions begin with a START (S) and can be terminated by a STOP (P). A HIGH to LOW transition on the SDA line while SCL is HIGH defines a START condition. A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP condition. START and STOP conditions are always generated by the master. The bus is considered to be busy after the START condition. The bus is considered to be free again a certain time after the STOP condition. Every byte put on the SDA line must be 8 bits long. The number of bytes that can be transmitted per transfer is unrestricted. Each byte has to be followed by an Acknowledge bit. Data is transferred with the Most Significant Bit (MSB) first. The acknowledge takes place after every byte. The acknowledge bit allows the receiver to signal the transmitter that the byte was successfully received and another byte may be sent. All clock pulses including the acknowledge 9th clock pulse are generated by the master. If the master–receiver signals a not-acknowledge, this indicates to the slave–transmitter that this byte was the last byte of the transfer. 4. AES-GCM The key feature of the AES-GCM is that the Galois Field multiplication used for authentication can be easily computed in parallel [21]. This approach permits higher throughput than the authentication algorithms that use chaining modes, like CBC. GCM mode is used in the IEEE 802.1AE (MACsec) [22] Ethernet security standard, ANSI (INCITS) Fibre Channel Security Protocols (FC-SP) [23], IEEE P1619.1 tape storage specification [24], and IETF IPSec standards [25]. Other interesting point is that since it is a counter mode algorithm (what is encrypted is a counter, not the data, encryption and decryption are done using the same circuit). Lastly, the authentication is an integral part of the encryption process and, thus, does not incur in extra hardware or software. The GCM encryption operation is defined by several equations [26]. The first step is to calculate H, one of the factors of the GF128 product. To do so, a vector consisting of 128 zeroes is encrypted using the K key. The result is the H vector. The second step is to calculate the initial value of the counter. This initial value ðY 0 Þ can be calculated in two different ways depending on the length of the initial vector ðIVÞ. If the Initial vector is 96 bit wide, Y 0 is obtained appending 31 zeroes and a single ‘1’. Otherwise, Y 0 is the result of multiplying, in GF128, the H vector and IV. This initial counter is incremented whenever a new word is encrypted and authenticated. This increment only affects the lower 32 bits of the counter.
Y i ¼ Y 127!32 k Y 31!0 þ1 i1 i1
ð1Þ
The encryption of the data ðCÞ is done xoring the plaintext data ðPÞ with the encrypted counter ðEðK; Y i ÞÞ using the initial key ðKÞ. The algorithm used is 128 bit AES. It must be noted that the last plaintext data may not be a multiple of 128. In this case the plaintext is padded using ‘0’ but the resulting C has only as many bits valid as the original P data.
208
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
Data authentication is performed using a GF128 multiplier and multiplying the input data by the H vector. The output of this multiplier is denoted as X. The initial value of X is the all zeroes vector. First of all, the data only to be authenticated ðAÞ is passed through the multiplier. This data is padded with zeroes to be a multiple of 128.
X i ¼ ðX i1 Ai Þ H
ð2Þ
In a second stage all the data to be encrypted and authenticated is passed through the multiplier, to do so, the C vector is used. The C vector is also padded with zeroes to be a multiple of 128.
X i ¼ ðX i1 C i Þ H
ð3Þ
The last stage corresponds to the multiplication of the lengths of the A part and the C part. To do so, the length in bits of both parts is calculated and padded with zeroes to be have length 64 bits. Both lengths are then concatenated, first A length and afterward C length. This value is used in the multiplier as follows.
X last ¼ ðX last1 ðlenðAÞklenðCÞÞÞ H
ð4Þ
The value of the authenticating tag ðTÞ is found using the last X value and the encrypted value of the initial state of the counter.
T ¼ X last EðK; Y 0 Þ
ð5Þ
Due to the internal structure of the algorithm, the decryption is done in the same way as encryption.equations: 5. I2CSEC: secured I2C protocol In order to define a secured I2C protocol, the next guides have been taken into account: The use of an already proven security scheme. The compatibility of the secured I2C device with the conventional ones. The first point has been achieved using AES-GCM. GCM mode combines the counter mode of encryption with the new Galois mode of authentication. The second point has been solved by using the block write and read capabilities from the I2C standard. In this mode, several bytes can be read or written in the same transactions. The secured I2C protocol defines the next two basic operations: Write into slave Read from the slave 5.1. Data transactions First a write into a slave (see Fig. 1) will be explained: The Master asserts an START condition, writes the slave device address an clears the write bit. These operations follows the 7 bit addressing mode defined in the I2C standard. Once the slave acknowledges the address, the master begins to send the data. This data can be encrypted and authenticated or only authenticated (one of the features of the AES-GCM algorithm). When the Master finishes writing data, it continues writing the 128 bit signature for authentication (16 words). The Master asserts the STOP condition. The Slave realizes that the communications has ended, and it can decrypt and check the signature.
Second a read from the slave (see Fig. 2) is presented: The master asserts a START condition, writes the slave device address an sets the write bit (meaning it wants to read) using the 7 bit I2C addressing mode. Once the slave acknowledges the address (ACK), the slave sends the length of the data. After the length, it begins to send the data. This data can be encrypted and authenticated or only authenticated. Once the slave finishes the data to be transmitted, it continues writing the 128 bit signature for authentication (16 words). The master writes a not acknowledge (NO ACK) once the signature is read and asserts the STOP condition, following the I2C standard way of signalling the slave transmitter that the end of the transfer. The master knows that the communications has ended, and it can decrypt and check the signature. Reads from the slave differ from writes in the slave in the length parameter. The master does not need to assert the length of the data it is transmitting since it has control of the bus and, when it wants to end the communication it only needs to assert the STOP condition. On the other hand, the slave has not this ability and thus, it must use a length parameter to inform the master. It must also be noted that if the I2CSec bus master is capable of both secured and not secured communications, both type of slaves can share the same communication link. The main reason is that the physical and link layer do not defer from the standard I2C and thus all I2CSec Master hardware is the same, with only minor software changes required for both communications.
5.2. Key management This is a very important issue, and in this application we have resolved it in two ways, depending on the type of application: Low cost, low data transfer systems Enhanced security systems In the first case, it is assumed that keys do not need to be changed frequently and that there is physical security during the installation process. In this case, the key, initial vector and slave address are embedded in the FPGA bitstream. This process must be performed in a secured environment since all this data must be passed to the master. This can be done using a air-gap network where every bitstream for every slave is generated and downloaded to the target. At the same time, all the keys are stored, transferred to the master bitstream (using a read only memory block ram inside the FPGA, for example) and finally they are downloaded to the master. Once the process is finished, all the generated bitstreams are deleted or securely stored. Once the system is working, if we would like to change the keys, we could use special slave registers. By making public the internal register (that is, making the accessible through the I2C), the master could change a slave key. The problem is that the key is volatile and, in case of power failure, it would revert to the original one. If the key is stored in outside memory, it requires some extra hardware and, it could be easily be eavesdropped. In the second case, the problem is solved building a complex key exchange mechanism. The mechanism is explained in Ref. [27] where it is used in a secured domotic application. During bitstream generation, the public key of the master is embedded. Once the system is deployed, the slaves turn on using a bitstream that is in charge of the RSA key exchange. Using the public key, the AES
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
209
Fig. 1. I2CSec block write.
Fig. 2. I2CSec block read.
key is interchanged. The key is created by the slave at runtime and stored. Once the key interchange is ended, the Slave loads a second bitstream with the usual I2CSec cores. The problem with this second approach is that slave modules are more complex and thus, they require bigger FPGAs. One interesting option is the Spartan 3AN. This FPGA has internal flash memory and one time program-
mable registers. Using this FPGA, all the keys and initial vectors can safely be stored inside the FPGA, making it very difficult eavesdropping. The master is also a little bit more complex and, taking into account the high security scheme it seem reasonable to use a Virtex or Spartan 6 FPGA so that en encrypted bitstream can be used.
Reduced experimental setup
MASTER
I2CSec Slave 0
I2CSec Slave 1
I2CSec Slave 2
I2C Slave 3
I2C Slave 4
I2C Slave 5
Fig. 3. Generic system using the proposed scheme. The experimental setup is a simplified version that only has a master and a slave.
210
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
FPGA Spartan 3E500
PLB
xps_uartlite
xps_intc
microblaze
xps_iic
xps_ethernetlite
mpmc
xps_gpio
DDR SDRAM
xps_timer
Fig. 4. Block diagram of the I2CSec Master. The system is built around a microblaze soft processor.
FPGA Spartan 3 200
wish_iic_secured picoblaze wish_io
Fig. 5. Block diagram of the I2CSec Slave. The system is built around a picoblaze soft processor.
K
PICO−CTRL
SH MEM
GF128 WB IF
PICO−AES
SBOX
IV FIFO
PLAINTEXT
ADDRESS I2C Slave core STATE
Fig. 6. Block diagram of the wishbone I2C securing block. The system is built around two picoblaze soft processor. One in charge of controlling the system, the other of performing the encryption.
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
The application we are focusing is a low cost and low data transfer, so the application results will be given for the first case. It must be noted that inside the same network, both kind of slaves can coexist, so high security slaves could use the second system, secured slave the first and even non secured slaves could populate the network.
In order to validate the proposed protocol and to evaluate its applicability in commercial applications, an experimental setup composed of an I2CSec Master implemented in a medium size FPGA and a I2CSec slave implemented in a low cost FPGA has been developed. In Fig. 3 a generic setup can be seen. The experimental setup only has a master and a slave (first two elements). This generic system has both secured and not secured elements. 6.1. I2CSec Master The strategy used for the I2CSec implementation in the master is based on Platform Based Design. All the IPs are reused, and all the security related computations are carried out by the microblaze 32 bit processor. In the master, the I2CSec communication is only one task in the SoPC. Depending on the applications, the SoPC will have different peripherals and software. Thus, thanks to the software computations selected the cost, in term of resources, of the I2C secured is minimal for the master. Since the I2C Master core is completely standard, the basic input/output functions are done using the standard API provided by Xilinx. The I2CSec Master circuit is built around an Spartan6lx16 FPGA. The system is built using the Xilinx Platform Studio [28] and only uses standard IP cores. The system is composed of the following main elements (see Fig. 4): 1. microblaze soft processor. This 32 bit processor is in charge of performing all the encryption/decryption by software. It is also in charge of the TCP/IP communications as well as controlling some generic input/outputs. 2. xps_iic PLB core. This standard IP core is in charge of I2C communication and is connected to the main processor through a PLB bus. 3. xps_ethernetlite PLB core. This element is in charge of the high speed ethernet communication towards Internet.
Table 1 Resource utilization of the I2CSec Master (xc6slx16). Logic utilization
Used
Available
Utilization (%)
Number Number Number Number Number Number
4162 4983 1828 9 3 1
18224 9112 2278 32 32 2
48 54 80 28 9 50
slice flip flops 6 input LUTs occupied slices RAMB16s DSP48s PLL
Table 2 Resource utilization of the I2CSec slave (xc6slx4). Logic utilization
Used
Available
Utilization (%)
Number Number Number Number
1012 1442 464 8
4800 2400 600 24
21 60 77 33
of of of of
slice flip flops 6 input LUTs occupied slices RAMB8s
4. mpmc memory controller. This block is in charge of managing memory access towards an external SDRAM. The software needed to perform the encryption/decryption plus the TCP stack plus all the system control can be big enough to require external storage. 6.2. I2CSec slave
6. Experimental setup
of of of of of of
211
The strategy for the I2CSec slave is completely different compared to the master. The slave modules will be implemented in smaller and cheaper FPGAs, so the resource optimization is vital. Instead of following platform based design, embedding a huge 32 bit soft processor that carries out the cryptography computation, a custom low speed AES-GCM that combines a software AES implementation in a minimal 8 bit microprocessor and a hardware GCM multiplier is used. The I2CSec Slave circuit is built around a Spartan6lx4 FPGA. The system is built using Wishbone interconnection bus [29]. The system is composed of the following main elements (see Fig. 5): 1. picoblaze soft processor [30]. This 8 bit processor is in charge of controlling the communications and some generic input/ outputs. 2. wish_iic_secured Wishbone core. This IP core is in charge of I2CSec communication and of the encryption/decryption of the outgoing/incoming data. It is connected to the main processor through a Wishbone bus. 3. wish_io Wishbone core. This element is in charge of controlling some generic input and outputs. The main element is the wish_iic_secured. This core is composed of two main parts, an I2CSec Slave module and an AES-GCM module. The AES-GCM module is built around two Picoblaze soft processors; one is in charge of the AES encryption [31] while the other is in charge of the communication with the I2CSec Slave module and the wishbone interface. A detailed description can be seen in Fig. 6. This dual core arrangement makes it possible to receive data and decrypt simultaneously. The wishbone interface is in charge of writing and reading from internal registers where de key, initial vector, plaintext,. . .are stored. The main reason is that the width of the wishbone (8 bit) is smaller than the parameters (128 bit for the key). Once all the parameters are stored, the soft microprocessor in charge of the control (pico-ctrl reads the data and passes the required parameters, using a shared memory (sh mem) to the processor in charge of the AES encryption. It also directly passes data to the Galois Field serial multiplier. This multiplier is done using a serial register and requires 128 clock cycles to complete its task. The connection between the encryption block and the I2C interface is done using a FIFO. 7. Implementation results The I2CSec Master is the biggest of both circuits since it is based on a 32 bit microprocessor. The resource utilization is shown in Table 1. This design takes around 50% of the generic resources. This leaves enough space to introduce application specific cores as motor controllers or generic input/outputs. It must be noted that this basic system is capable of communicating through a high speed Ethernet connection towards Internet, thus allowing the remote control and monitoring of any industrial system using I2C. The I2CSec Slave is built around a low cost Spartan6lx4. The system takes around 75% of the resources (see Table 2) leaving plenty of space for application specific cores. Examples of such system could be far more generic input and outputs, PWM motor controllers, motor encoders or analog sensors.
212
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
8. Comparison with other systems There are not many secure low speed communication protocols, and even less are done inside a FPGA. Lonworks in an example of such a system. One version of the domotic protocol is implemented inside a Cyclone II/III FPGA [32]. It makes use of an external transceiver, a hardware core and a software program running on a Nios soft processor. The size of such element is very similar to that of our proposed master but much bigger than our slaves. Basically the FPGA core is designed to be a master or part of a very complex slave. As mentioned before Lonworks only provides basic authentication, with no security against eavesdropping. KNX open standard does not offer any kind of security measure. In order to provide KNX with security, there has been several proposals. One of the most important is EIBSec. The main goal of EIBsec is to protect the control network against local attacks. EIBSec uses AES-128 in two different fashions, one normal mode used during session establishment and group key retrieval. The second mode, called counter mode, is used for transmitting management (unicast) and process (group) data once the secure channel is established. It is based on the Secure Network Encryption Protocol [16] and Secure EIB [33]. While it provides a high degree of security there are not implementation results so comparison in terms of area or speed are not possible. But we may compare them in terms of security. Both systems use AES-128 although in two different modes. EIBSec uses normal and counter mode, our approach uses GCM. According to NSA Suite B which regulates both unclassified information and most classified information states that AES should be used in GCM mode. Other point of comparison is hardware implementation. Most microcontrollers would easily fulfill the required tasks and possibly for a fraction of the cost of a basic FPGA. In fact, there exist many microcontrollers with embedded AES hardware to accelerate encryption process. The main problems with this kind of systems are that the may need external memory, which can be tampered and that they lack the flexibility of a reconfigurable system.
9. Conclusion In this paper a secure Chip-to-Chip protocol has been presented, I2CSec. It is compatible with I2C standard and it can be implemented on digital systems with standard I2C peripherals. It is based on a well known cryptographic mode of operation, AES-GCM, which supports both encryption and authentication. The proposed protocol allows master–slave block read and write operations. Thanks to these block operations, the overload generated by the injection of the MAC words that ensure the authentication is minimized. The implementation of the I2CSec presented in the paper has been optimized for FPGA devices. On one hand, the proposed master is a SoPC that supports I2CSec. In this case, a general purpose 32 bit soft processor is in charge of processing all the cryptography computations, and a standard I2C peripheral carries the I2C communications. On the other hand, the I2CSec slave is implemented on a small FPGA with a custom design that minimizes the required FPGA resources and gives the requested computation power. The proposed solution is based on a multiprocessor architecture that benefits of the tiny 8 bit soft processors available for Xilinx devices. The implementation results validate the applicability of the proposed protocol and show the FPGAs as the perfect candidates for the implementation of secured serial communication links that require strong computations and flexibility in their implementations. An FPGA may be more suitable than a microprocessor thanks to the possibility of wide range of input output schemes as well as the capability to reconfigure the encryption algorithm. GCM is defined to use AES but it also lets use other encryption algorithms,
the flexibility of FPGAs may be of great interest if a change in the encryption scheme is possible. Future work in this field includes the design a mixed-signal sensor that supports the protocol and the enhancement of the protocol with a key interchange protocol.
Acknowledgements This work has been partially supported by the Government of the Basque Country within the research program SAIOTEK (project SA-2010/40) and by Ministerio de Ciencia e Innovación of Spain within the project TEC2010-21196-02-01.
References [1] D.D. Hwang, P. Schaumont, K. Tiri, I. Verbauwhede, Securing embedded systems, IEEE Security and Privacy 4 (2) (2006) 40–49. [2] I. Freescale Semiconductor, ColdFire Security: SEC and Hardware Encryption Acceleration Overview, Freescale Semiconductor Application Note 2788, 2003.. [3] G. Martin, H. Chang (Eds.), Winning the SoC Revolution: Experiences in Real Design, Kluwer Academic Publishers, Massachusetts, USA, 2003. [4] Y.Z.R.K. Gupta, Introducing core-based system design, IEEE Design and Test of Computers 14 (4) (1997) 15–25. [5] R.A. Bergamaschi, S. Bhattacharya, R. Wagner, C. Fellenz, M. Muhlada, Automating the design of SOCs using cores, IEEE Design and Test of Computers 18 (5) (2001) 32–45. [6] G. Martin, H. Chang (Eds.), Winning the SoC Revolution: Experiences in Real Design, Kluwer Academic Publishers, 2003. [7] R. Graham, D. Maynor, SCADA Security and Terrorism: We’re Not Crying Wolf, Technical Report, Internet Security Systems, 2009. [8] DNP3, Distributed Network Protocol, 1993. URL: . [15] M. Luk, G. Mezzour, A. Perrig, V. Gligor, Minisec: a secure sensor network communication architecture, in: IPSN ’07: Proceedings of the 6th International Conference on Information Processing in Sensor Networks, ACM, New York, NY, USA, 2007, pp. 479–488. doi:. [16] A. Perrig, R. Szewczyk, V. Wen, D. Culler, J.D. Tygar, SPINS: security protocols for sensor networks, Wireless Networks 8 (5) (2002) 521–534. [17] Ionworks, Echelon, 2010. URL: . [18] STANDARD for Home and Building Control: KNX, KNX, 2010. URL: . [19] W. Granzer, G. Neugschwandtner, W. Kastner, EIBsec: a security extension to KNX/EIB, in: Konnex Scientific Conference, 2006. URL: . [20] NXP, I2C-bus specification and user manual, UM10204, June 2007. URL: . [21] J. Lazaro, A. Astarloa, U. Bidarte, J. Jimenez, A. Zuloaga, AES-galois counter mode encryption/decryption FPGA core for industrial and residential gigabit ethernet communications, Lecture Notes in Computer Science 5453 (2009) 312–317. [22] IEEE 802.1AE-2006 Media Access Control (MAC) Security, IEEE Standards Department, 2006. URL: . [23] A.N.S. for Information Technology, Fibre Channel Security Protocols (FC-SP), INCITS 1570-D. URL: . [24] P1619.1: Standard for Authenticated Encryption with Length Expansion for Storage Devices, IEEE Standards Department, 2006. URL: . [25] J. Viega, D. McGrew, The Use of Galois/Counter Mode (GCM)in IPsec Encapsulating Security Payload (ESP), RFC4106, June 2005. URL: . [26] D. McGrew, J. Viega, The Galois/Counter Mode of Operation (GCM), 2004. URL: .
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213 [27] J. Lazaro, A. Astarloa, U. Bidarte, A. Zuloaga, J. Jimenez, CRYx-BCU: a security oriented cost-conscious SoPC implementation for Bus Coupling Units of the European Installation Bus, in: Proceedings of AE09, 2009. [28] Xilinx Corp., Xilinx Platform Studio and EDK, Xilinx Documentation, 2009.. [29] Silicore Corporation, Wishbone System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores Revision: B.3, September 2002. . [30] K. Chapman, PicoBlaze 8-Bit Microcontroller for Virtex-E and Spartan II/IIE Devices, Xilinx Application Notes, February 2003. . [31] H.V. Kampen, PicoBlaze Rijndael (AES-128) Block Cipher, 2003. . [32] FTXL, Echelon, 2010. URL: . [33] K. Werthschulte, G. Westermeir, F. Schneider, T.U. München, Secured data transmission for control and supervision of an eib installation using mixed network topologies, Technische Universität München/eib Event, 2001. Jesús Lázaro received the M.S. and Ph.D. degrees in telecommunications engineering from the University of the Basque Country, Spain, in 2001 and 2005, respectively. Since 2001 he is Assistant Professor in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. His main research interests are Reconfigurable Circuits and System-on-Chip.
Armando Astarloa received the M.S. and Ph.D. degrees in electrical engineering from the University of the Basque Country, Spain, in 1999 and 2005, respectively. From 1999 to 2001, he worked as R&D engineer for a private company. Since 2001 he is Assistant Lecturer in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. His main research interests are Reconfigurable Circuits, System-on-Chip and Digital Communications Circuits.
213
Aitzol Zuloaga received the B.S. degree in electrical engineering and M.S. degree in project management from the Simón Bolivar University, Venezuela, in 1985 and 1992, respectively, and Ph.D. degrees in telecommunications engineering from the University of the Basque Country, Spain, 2001. From 1985 to 1995 he was with different R&D departments of private companies in Venezuela. In 1995, he joined the University of the Basque Country with a predoctoral grant. In 2000 he became Assistant Professor in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. His main research interests are Image Processing, System-on-Chip, and Digital Communications Circuits. Unai Bidarte received the M.S. and Ph.D. degrees in telecommunications engineering from the University of the Basque Country, Spain, in 1996 and 2004, respectively. Since 1999 he is Assistant Professor in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. His main research interests are Reconfigurable Circuits, System-on-Chip and Digital Communications Circuits.
Jaime Jiménez received the M.S. degree in telecommunications engineering from the University of the Basque Country, Spain, in 1991. From 1991 to 1997, he was with the Robotiker Technological Center and the Basque Government. Since 1998 he is Assistant Professor in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. In 2005 he received the Ph.D. degree in telecommunicactions engineering. His main research interests are Design Methodologies, Systemon-Chip and Digital Communications Circuits.
Contents lists available at ScienceDirect
Journal of Systems Architecture journal homepage: www.elsevier.com/locate/sysarc
I2CSec: A secure serial Chip-to-Chip communication protocol Jesús Lázaro ⇑, Armando Astarloa, Aitzol Zuloaga, Unai Bidarte, Jaime Jiménez University of the Basque Country, Department of Electronics and Telecommunications Alameda Urquijo s/n, Bilbao, Spain
a r t i c l e
i n f o
Article history: Received 4 May 2010 Received in revised form 21 October 2010 Accepted 10 December 2010 Available online 30 December 2010 Keywords: FPGA I2C Communication security AES-GCM
a b s t r a c t This paper presents a secured I2C (Inter-Integrated Circuit) protocol for Chip-to-Chip communications. The well known AES-GCM cryptographic and authentication algorithm is used to secure this low speed serial communication protocol. This securization allows the use of this standard into applications where security is an issue and the computation resources are constrained. Both the hardware architecture and the protocol are presented. The implementation of the I2CSec presented in the paper has been optimized for FPGA devices. Ó 2010 Elsevier B.V. All rights reserved.
1. Introduction This paper presents a basic I2C network that can be secured. This kind of low speed networks are used to control a great variety of peripherals in embedded systems. These embedded systems are present in a great variety of industrial applications due to its simplicity and availability. One problem that arises when using this kind of networks is the secrecy and privacy of the system. In some critical control applications, knowing that data is coming from the sensor and not from a malicious user is critical. The approach presented in this paper, fulfills this security requirements while, at the same time, remains within the price constrains of an embedded system. The proposed implementation assumes that the slave or master device (and configuration bitstream) is not tampered with, in other words, it is only focused in securing the communications. The cryptographic algorithms computation requirements are so high for a conventional embedded processor device, that most of its computation capacity would be needed if that computation was performed by software. For many embedded systems, this situation is not affordable [1]. In order to deal with this drawback, processors most commonly used for industrial applications such as ColdFire, have embedded cryptographic cores (crypto-cores) in the same device [2]. Using this approach, the frame encryption and decryption is performed by hardware, freeing the main processor core from this task. The main drawback of this approach is the limited flexibility that it shows. These embedded processors are ASIC technology. Thus, ⇑ Corresponding author. E-mail addresses: [email protected] (J. Lázaro), [email protected] (A. Astarloa), [email protected] (A. Zuloaga), [email protected] (U. Bidarte), [email protected] (J. Jiménez). 1383-7621/$ - see front matter Ó 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.sysarc.2010.12.001
the crypto-core is fixed on terms of algorithm implementation and interfaces; both for the software interface and for the communication media controller peripheral or core. Besides, the ASIC processor-based solution, the industry is massively adopting the core-based design methodology for system integration using Field Programmable Gate Arrays (FPGA), which leads to the appearance of the System-on-Programmable-Chip (SoPC) platforms [3]. Taking into account the fact that FPGAs do not incur in non-recurring engineering charges due to their reconfigurable nature, the number and diversity of the available IP cores for digital systems composition has heavily increased [4,5]. The SoPCs are very flexible in different ways: number and type of IP cores and processors, bus architecture, hardware and software co-processing, etc. This flexibility allows very short time-to-market and facilitates custom device design for every industry and application. The SoPC technology faces the secure communication paradigm with the maximum flexibility: depending on the application, different crypto-cores and communication media controller cores can be included in the FPGA device. For the secure communication section of the SoPC, the designer is in charge of finding the best FPGA resource occupation-data throughput trade-off and the optimum IP license cost as well. Typically, the technology for the embedded systems for this market has been dominated by the microcontrollers. However, nowadays, the computational power and flexibility that reconfigurable platforms offer are closer to this market. The main FPGA vendors, Xilinx and Altera, offer low-cost devices oriented to the consumer market. The actual options hardly justify the high cost of a custom ASIC processor-based approach for medium sized productions. In fact, some sectors have adopted the core-based design methodology for system integration using FPGAs [6]. This design flow simplifies and speeds-up the design of complex systems
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
which allows very short time-to-market and facilitates custom device design for every industry and application. Chip-to-Chip communication links are present in most of the digital systems. SPI or I2C standards are only an example and their use is being extended to security sensitive applications like sensors connections, RFID, biometric devices, etc. These links can benefit of FPGAs in order to secure the communication. Target applications of this technology are located in secure conscious environments for example securization of sensor to processor communications in industrial plants. When domotic applications want to increase they capabilities by including intrusion detection, they greatly benefit from a secured communications scheme. It must be noted that the proposed algorithm not only protects against eavesdropping but it also guarantees that the information is received from a trusted source. 2. Low speed communications security approaches There are two main areas in the low speed secured communications. One of them are wireless communications and the other industrial control like SCADA. The algorithm that we propose is suited for industrial control, specially because I2C is a very common communication standard between microcontrollers and sensors. Because our approach is so highly related to industrial control, we will begin by SCADA systems. SCADA stands for supervisory control and data acquisition. The term SCADA usually refers to centralized systems which monitor and control entire sites, or complexes of systems spread out over large areas. SCADA may control highly sensitive processes, so security is an issue [7]. In the past, SCADA systems where proprietary and where restricted to the site they where controlling. This assumed that any attacker had to gain physical access to the facility and that he had to had very specialize knowledge. In the past years, SCADA system are changing from proprietary to open source and from isolated to Internet controlled systems. This means that they are far more vulnerable and that security measures are compulsory. Specially these measures are focused in the Internet access part (DNP3 [8], RTAP [9], IF-MAP [10], Realflex [11]). But one question arises, was the original security assumption correct? Most onsite communications are not IP, they are field communications using standards such as Modbus [12], which do not have security concerns. This means that no matter how many security layers we put on our Internet connections, an intruder could bypass all of them just by gaining physical access. Another different scenario are Wireless sensor networks (WSN) [13]. In this scenario, the physical security of the sensors is compromised so steps must be taken to ensure security, both by authentication (knowing that the sensor is really what we thing) and by encryption (making our conversations secret). There are some particularities in WSN, first of all the resources, both energy and computational. Secondly deployment may not be controlled, for example they may be air-dropped. Examples of security aware protocols include TinySec [14], MiniSec [15], SPINS [16], etc. The proposed protocol fills a gap between both systems. It is focused on wired systems that do have power to spare but not processing power. The placement is definitively controlled but physical security is not guaranteed. This gap is also of interest for domotic applications, Lonworks [17] provides basic authentication scheme while KNX [18] has several security proposals such as EIBSec [19]. 3. I2C The I2C-bus [20] is a de facto world standard that is now implemented in over 1000 different ICs manufactured by more than 50
207
companies. Two wires, serial data (SDA) and serial clock (SCL), carry information between the devices connected to the bus. Each device is recognized by a unique address (whether it is a microcontroller, LCD driver, memory or keyboard interface) and can operate as either a transmitter or receiver, depending on the function of the device. Generation of clock signals on the I2C-bus is always the responsibility of master devices; each master generates its own clock signals when transferring data on the bus. All transactions begin with a START (S) and can be terminated by a STOP (P). A HIGH to LOW transition on the SDA line while SCL is HIGH defines a START condition. A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP condition. START and STOP conditions are always generated by the master. The bus is considered to be busy after the START condition. The bus is considered to be free again a certain time after the STOP condition. Every byte put on the SDA line must be 8 bits long. The number of bytes that can be transmitted per transfer is unrestricted. Each byte has to be followed by an Acknowledge bit. Data is transferred with the Most Significant Bit (MSB) first. The acknowledge takes place after every byte. The acknowledge bit allows the receiver to signal the transmitter that the byte was successfully received and another byte may be sent. All clock pulses including the acknowledge 9th clock pulse are generated by the master. If the master–receiver signals a not-acknowledge, this indicates to the slave–transmitter that this byte was the last byte of the transfer. 4. AES-GCM The key feature of the AES-GCM is that the Galois Field multiplication used for authentication can be easily computed in parallel [21]. This approach permits higher throughput than the authentication algorithms that use chaining modes, like CBC. GCM mode is used in the IEEE 802.1AE (MACsec) [22] Ethernet security standard, ANSI (INCITS) Fibre Channel Security Protocols (FC-SP) [23], IEEE P1619.1 tape storage specification [24], and IETF IPSec standards [25]. Other interesting point is that since it is a counter mode algorithm (what is encrypted is a counter, not the data, encryption and decryption are done using the same circuit). Lastly, the authentication is an integral part of the encryption process and, thus, does not incur in extra hardware or software. The GCM encryption operation is defined by several equations [26]. The first step is to calculate H, one of the factors of the GF128 product. To do so, a vector consisting of 128 zeroes is encrypted using the K key. The result is the H vector. The second step is to calculate the initial value of the counter. This initial value ðY 0 Þ can be calculated in two different ways depending on the length of the initial vector ðIVÞ. If the Initial vector is 96 bit wide, Y 0 is obtained appending 31 zeroes and a single ‘1’. Otherwise, Y 0 is the result of multiplying, in GF128, the H vector and IV. This initial counter is incremented whenever a new word is encrypted and authenticated. This increment only affects the lower 32 bits of the counter.
Y i ¼ Y 127!32 k Y 31!0 þ1 i1 i1
ð1Þ
The encryption of the data ðCÞ is done xoring the plaintext data ðPÞ with the encrypted counter ðEðK; Y i ÞÞ using the initial key ðKÞ. The algorithm used is 128 bit AES. It must be noted that the last plaintext data may not be a multiple of 128. In this case the plaintext is padded using ‘0’ but the resulting C has only as many bits valid as the original P data.
208
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
Data authentication is performed using a GF128 multiplier and multiplying the input data by the H vector. The output of this multiplier is denoted as X. The initial value of X is the all zeroes vector. First of all, the data only to be authenticated ðAÞ is passed through the multiplier. This data is padded with zeroes to be a multiple of 128.
X i ¼ ðX i1 Ai Þ H
ð2Þ
In a second stage all the data to be encrypted and authenticated is passed through the multiplier, to do so, the C vector is used. The C vector is also padded with zeroes to be a multiple of 128.
X i ¼ ðX i1 C i Þ H
ð3Þ
The last stage corresponds to the multiplication of the lengths of the A part and the C part. To do so, the length in bits of both parts is calculated and padded with zeroes to be have length 64 bits. Both lengths are then concatenated, first A length and afterward C length. This value is used in the multiplier as follows.
X last ¼ ðX last1 ðlenðAÞklenðCÞÞÞ H
ð4Þ
The value of the authenticating tag ðTÞ is found using the last X value and the encrypted value of the initial state of the counter.
T ¼ X last EðK; Y 0 Þ
ð5Þ
Due to the internal structure of the algorithm, the decryption is done in the same way as encryption.equations: 5. I2CSEC: secured I2C protocol In order to define a secured I2C protocol, the next guides have been taken into account: The use of an already proven security scheme. The compatibility of the secured I2C device with the conventional ones. The first point has been achieved using AES-GCM. GCM mode combines the counter mode of encryption with the new Galois mode of authentication. The second point has been solved by using the block write and read capabilities from the I2C standard. In this mode, several bytes can be read or written in the same transactions. The secured I2C protocol defines the next two basic operations: Write into slave Read from the slave 5.1. Data transactions First a write into a slave (see Fig. 1) will be explained: The Master asserts an START condition, writes the slave device address an clears the write bit. These operations follows the 7 bit addressing mode defined in the I2C standard. Once the slave acknowledges the address, the master begins to send the data. This data can be encrypted and authenticated or only authenticated (one of the features of the AES-GCM algorithm). When the Master finishes writing data, it continues writing the 128 bit signature for authentication (16 words). The Master asserts the STOP condition. The Slave realizes that the communications has ended, and it can decrypt and check the signature.
Second a read from the slave (see Fig. 2) is presented: The master asserts a START condition, writes the slave device address an sets the write bit (meaning it wants to read) using the 7 bit I2C addressing mode. Once the slave acknowledges the address (ACK), the slave sends the length of the data. After the length, it begins to send the data. This data can be encrypted and authenticated or only authenticated. Once the slave finishes the data to be transmitted, it continues writing the 128 bit signature for authentication (16 words). The master writes a not acknowledge (NO ACK) once the signature is read and asserts the STOP condition, following the I2C standard way of signalling the slave transmitter that the end of the transfer. The master knows that the communications has ended, and it can decrypt and check the signature. Reads from the slave differ from writes in the slave in the length parameter. The master does not need to assert the length of the data it is transmitting since it has control of the bus and, when it wants to end the communication it only needs to assert the STOP condition. On the other hand, the slave has not this ability and thus, it must use a length parameter to inform the master. It must also be noted that if the I2CSec bus master is capable of both secured and not secured communications, both type of slaves can share the same communication link. The main reason is that the physical and link layer do not defer from the standard I2C and thus all I2CSec Master hardware is the same, with only minor software changes required for both communications.
5.2. Key management This is a very important issue, and in this application we have resolved it in two ways, depending on the type of application: Low cost, low data transfer systems Enhanced security systems In the first case, it is assumed that keys do not need to be changed frequently and that there is physical security during the installation process. In this case, the key, initial vector and slave address are embedded in the FPGA bitstream. This process must be performed in a secured environment since all this data must be passed to the master. This can be done using a air-gap network where every bitstream for every slave is generated and downloaded to the target. At the same time, all the keys are stored, transferred to the master bitstream (using a read only memory block ram inside the FPGA, for example) and finally they are downloaded to the master. Once the process is finished, all the generated bitstreams are deleted or securely stored. Once the system is working, if we would like to change the keys, we could use special slave registers. By making public the internal register (that is, making the accessible through the I2C), the master could change a slave key. The problem is that the key is volatile and, in case of power failure, it would revert to the original one. If the key is stored in outside memory, it requires some extra hardware and, it could be easily be eavesdropped. In the second case, the problem is solved building a complex key exchange mechanism. The mechanism is explained in Ref. [27] where it is used in a secured domotic application. During bitstream generation, the public key of the master is embedded. Once the system is deployed, the slaves turn on using a bitstream that is in charge of the RSA key exchange. Using the public key, the AES
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
209
Fig. 1. I2CSec block write.
Fig. 2. I2CSec block read.
key is interchanged. The key is created by the slave at runtime and stored. Once the key interchange is ended, the Slave loads a second bitstream with the usual I2CSec cores. The problem with this second approach is that slave modules are more complex and thus, they require bigger FPGAs. One interesting option is the Spartan 3AN. This FPGA has internal flash memory and one time program-
mable registers. Using this FPGA, all the keys and initial vectors can safely be stored inside the FPGA, making it very difficult eavesdropping. The master is also a little bit more complex and, taking into account the high security scheme it seem reasonable to use a Virtex or Spartan 6 FPGA so that en encrypted bitstream can be used.
Reduced experimental setup
MASTER
I2CSec Slave 0
I2CSec Slave 1
I2CSec Slave 2
I2C Slave 3
I2C Slave 4
I2C Slave 5
Fig. 3. Generic system using the proposed scheme. The experimental setup is a simplified version that only has a master and a slave.
210
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
FPGA Spartan 3E500
PLB
xps_uartlite
xps_intc
microblaze
xps_iic
xps_ethernetlite
mpmc
xps_gpio
DDR SDRAM
xps_timer
Fig. 4. Block diagram of the I2CSec Master. The system is built around a microblaze soft processor.
FPGA Spartan 3 200
wish_iic_secured picoblaze wish_io
Fig. 5. Block diagram of the I2CSec Slave. The system is built around a picoblaze soft processor.
K
PICO−CTRL
SH MEM
GF128 WB IF
PICO−AES
SBOX
IV FIFO
PLAINTEXT
ADDRESS I2C Slave core STATE
Fig. 6. Block diagram of the wishbone I2C securing block. The system is built around two picoblaze soft processor. One in charge of controlling the system, the other of performing the encryption.
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
The application we are focusing is a low cost and low data transfer, so the application results will be given for the first case. It must be noted that inside the same network, both kind of slaves can coexist, so high security slaves could use the second system, secured slave the first and even non secured slaves could populate the network.
In order to validate the proposed protocol and to evaluate its applicability in commercial applications, an experimental setup composed of an I2CSec Master implemented in a medium size FPGA and a I2CSec slave implemented in a low cost FPGA has been developed. In Fig. 3 a generic setup can be seen. The experimental setup only has a master and a slave (first two elements). This generic system has both secured and not secured elements. 6.1. I2CSec Master The strategy used for the I2CSec implementation in the master is based on Platform Based Design. All the IPs are reused, and all the security related computations are carried out by the microblaze 32 bit processor. In the master, the I2CSec communication is only one task in the SoPC. Depending on the applications, the SoPC will have different peripherals and software. Thus, thanks to the software computations selected the cost, in term of resources, of the I2C secured is minimal for the master. Since the I2C Master core is completely standard, the basic input/output functions are done using the standard API provided by Xilinx. The I2CSec Master circuit is built around an Spartan6lx16 FPGA. The system is built using the Xilinx Platform Studio [28] and only uses standard IP cores. The system is composed of the following main elements (see Fig. 4): 1. microblaze soft processor. This 32 bit processor is in charge of performing all the encryption/decryption by software. It is also in charge of the TCP/IP communications as well as controlling some generic input/outputs. 2. xps_iic PLB core. This standard IP core is in charge of I2C communication and is connected to the main processor through a PLB bus. 3. xps_ethernetlite PLB core. This element is in charge of the high speed ethernet communication towards Internet.
Table 1 Resource utilization of the I2CSec Master (xc6slx16). Logic utilization
Used
Available
Utilization (%)
Number Number Number Number Number Number
4162 4983 1828 9 3 1
18224 9112 2278 32 32 2
48 54 80 28 9 50
slice flip flops 6 input LUTs occupied slices RAMB16s DSP48s PLL
Table 2 Resource utilization of the I2CSec slave (xc6slx4). Logic utilization
Used
Available
Utilization (%)
Number Number Number Number
1012 1442 464 8
4800 2400 600 24
21 60 77 33
of of of of
slice flip flops 6 input LUTs occupied slices RAMB8s
4. mpmc memory controller. This block is in charge of managing memory access towards an external SDRAM. The software needed to perform the encryption/decryption plus the TCP stack plus all the system control can be big enough to require external storage. 6.2. I2CSec slave
6. Experimental setup
of of of of of of
211
The strategy for the I2CSec slave is completely different compared to the master. The slave modules will be implemented in smaller and cheaper FPGAs, so the resource optimization is vital. Instead of following platform based design, embedding a huge 32 bit soft processor that carries out the cryptography computation, a custom low speed AES-GCM that combines a software AES implementation in a minimal 8 bit microprocessor and a hardware GCM multiplier is used. The I2CSec Slave circuit is built around a Spartan6lx4 FPGA. The system is built using Wishbone interconnection bus [29]. The system is composed of the following main elements (see Fig. 5): 1. picoblaze soft processor [30]. This 8 bit processor is in charge of controlling the communications and some generic input/ outputs. 2. wish_iic_secured Wishbone core. This IP core is in charge of I2CSec communication and of the encryption/decryption of the outgoing/incoming data. It is connected to the main processor through a Wishbone bus. 3. wish_io Wishbone core. This element is in charge of controlling some generic input and outputs. The main element is the wish_iic_secured. This core is composed of two main parts, an I2CSec Slave module and an AES-GCM module. The AES-GCM module is built around two Picoblaze soft processors; one is in charge of the AES encryption [31] while the other is in charge of the communication with the I2CSec Slave module and the wishbone interface. A detailed description can be seen in Fig. 6. This dual core arrangement makes it possible to receive data and decrypt simultaneously. The wishbone interface is in charge of writing and reading from internal registers where de key, initial vector, plaintext,. . .are stored. The main reason is that the width of the wishbone (8 bit) is smaller than the parameters (128 bit for the key). Once all the parameters are stored, the soft microprocessor in charge of the control (pico-ctrl reads the data and passes the required parameters, using a shared memory (sh mem) to the processor in charge of the AES encryption. It also directly passes data to the Galois Field serial multiplier. This multiplier is done using a serial register and requires 128 clock cycles to complete its task. The connection between the encryption block and the I2C interface is done using a FIFO. 7. Implementation results The I2CSec Master is the biggest of both circuits since it is based on a 32 bit microprocessor. The resource utilization is shown in Table 1. This design takes around 50% of the generic resources. This leaves enough space to introduce application specific cores as motor controllers or generic input/outputs. It must be noted that this basic system is capable of communicating through a high speed Ethernet connection towards Internet, thus allowing the remote control and monitoring of any industrial system using I2C. The I2CSec Slave is built around a low cost Spartan6lx4. The system takes around 75% of the resources (see Table 2) leaving plenty of space for application specific cores. Examples of such system could be far more generic input and outputs, PWM motor controllers, motor encoders or analog sensors.
212
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213
8. Comparison with other systems There are not many secure low speed communication protocols, and even less are done inside a FPGA. Lonworks in an example of such a system. One version of the domotic protocol is implemented inside a Cyclone II/III FPGA [32]. It makes use of an external transceiver, a hardware core and a software program running on a Nios soft processor. The size of such element is very similar to that of our proposed master but much bigger than our slaves. Basically the FPGA core is designed to be a master or part of a very complex slave. As mentioned before Lonworks only provides basic authentication, with no security against eavesdropping. KNX open standard does not offer any kind of security measure. In order to provide KNX with security, there has been several proposals. One of the most important is EIBSec. The main goal of EIBsec is to protect the control network against local attacks. EIBSec uses AES-128 in two different fashions, one normal mode used during session establishment and group key retrieval. The second mode, called counter mode, is used for transmitting management (unicast) and process (group) data once the secure channel is established. It is based on the Secure Network Encryption Protocol [16] and Secure EIB [33]. While it provides a high degree of security there are not implementation results so comparison in terms of area or speed are not possible. But we may compare them in terms of security. Both systems use AES-128 although in two different modes. EIBSec uses normal and counter mode, our approach uses GCM. According to NSA Suite B which regulates both unclassified information and most classified information states that AES should be used in GCM mode. Other point of comparison is hardware implementation. Most microcontrollers would easily fulfill the required tasks and possibly for a fraction of the cost of a basic FPGA. In fact, there exist many microcontrollers with embedded AES hardware to accelerate encryption process. The main problems with this kind of systems are that the may need external memory, which can be tampered and that they lack the flexibility of a reconfigurable system.
9. Conclusion In this paper a secure Chip-to-Chip protocol has been presented, I2CSec. It is compatible with I2C standard and it can be implemented on digital systems with standard I2C peripherals. It is based on a well known cryptographic mode of operation, AES-GCM, which supports both encryption and authentication. The proposed protocol allows master–slave block read and write operations. Thanks to these block operations, the overload generated by the injection of the MAC words that ensure the authentication is minimized. The implementation of the I2CSec presented in the paper has been optimized for FPGA devices. On one hand, the proposed master is a SoPC that supports I2CSec. In this case, a general purpose 32 bit soft processor is in charge of processing all the cryptography computations, and a standard I2C peripheral carries the I2C communications. On the other hand, the I2CSec slave is implemented on a small FPGA with a custom design that minimizes the required FPGA resources and gives the requested computation power. The proposed solution is based on a multiprocessor architecture that benefits of the tiny 8 bit soft processors available for Xilinx devices. The implementation results validate the applicability of the proposed protocol and show the FPGAs as the perfect candidates for the implementation of secured serial communication links that require strong computations and flexibility in their implementations. An FPGA may be more suitable than a microprocessor thanks to the possibility of wide range of input output schemes as well as the capability to reconfigure the encryption algorithm. GCM is defined to use AES but it also lets use other encryption algorithms,
the flexibility of FPGAs may be of great interest if a change in the encryption scheme is possible. Future work in this field includes the design a mixed-signal sensor that supports the protocol and the enhancement of the protocol with a key interchange protocol.
Acknowledgements This work has been partially supported by the Government of the Basque Country within the research program SAIOTEK (project SA-2010/40) and by Ministerio de Ciencia e Innovación of Spain within the project TEC2010-21196-02-01.
References [1] D.D. Hwang, P. Schaumont, K. Tiri, I. Verbauwhede, Securing embedded systems, IEEE Security and Privacy 4 (2) (2006) 40–49. [2] I. Freescale Semiconductor, ColdFire Security: SEC and Hardware Encryption Acceleration Overview, Freescale Semiconductor Application Note 2788, 2003.
J. Lázaro et al. / Journal of Systems Architecture 57 (2011) 206–213 [27] J. Lazaro, A. Astarloa, U. Bidarte, A. Zuloaga, J. Jimenez, CRYx-BCU: a security oriented cost-conscious SoPC implementation for Bus Coupling Units of the European Installation Bus, in: Proceedings of AE09, 2009. [28] Xilinx Corp., Xilinx Platform Studio and EDK, Xilinx Documentation, 2009.
Armando Astarloa received the M.S. and Ph.D. degrees in electrical engineering from the University of the Basque Country, Spain, in 1999 and 2005, respectively. From 1999 to 2001, he worked as R&D engineer for a private company. Since 2001 he is Assistant Lecturer in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. His main research interests are Reconfigurable Circuits, System-on-Chip and Digital Communications Circuits.
213
Aitzol Zuloaga received the B.S. degree in electrical engineering and M.S. degree in project management from the Simón Bolivar University, Venezuela, in 1985 and 1992, respectively, and Ph.D. degrees in telecommunications engineering from the University of the Basque Country, Spain, 2001. From 1985 to 1995 he was with different R&D departments of private companies in Venezuela. In 1995, he joined the University of the Basque Country with a predoctoral grant. In 2000 he became Assistant Professor in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. His main research interests are Image Processing, System-on-Chip, and Digital Communications Circuits. Unai Bidarte received the M.S. and Ph.D. degrees in telecommunications engineering from the University of the Basque Country, Spain, in 1996 and 2004, respectively. Since 1999 he is Assistant Professor in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. His main research interests are Reconfigurable Circuits, System-on-Chip and Digital Communications Circuits.
Jaime Jiménez received the M.S. degree in telecommunications engineering from the University of the Basque Country, Spain, in 1991. From 1991 to 1997, he was with the Robotiker Technological Center and the Basque Government. Since 1998 he is Assistant Professor in electronic technology at the Electronics and Telecommunications Department of the University of the Basque Country. In 2005 he received the Ph.D. degree in telecommunicactions engineering. His main research interests are Design Methodologies, Systemon-Chip and Digital Communications Circuits.