PORTING A NETWORK CRYPTOGRAPHIC SERVICE TO THE RMC2000 : A CASE STUDY IN EMBEDDED SOFTWARE DEVELOPMENT

2 Porting a Network Cryptographic Service to RCM2000 About RCM2000

3 Porting a Network Cryptographic Service to RCM2000 About Dynamic C

4 Porting a Network Cryptographic Service to RCM2000 Reference site

5 Porting a Network Cryptographic Service to RCM2000 Introduction Experience porting a transport-layer cryptography service to an embedded microcontroller Some key development issues and techniques involved in porting networked software to a connected, limited resource device such as the Rabbit RCM2000 The effectiveness of a few proposed porting strategies by examining important program and run-time characteristics

6 NETWORK CRYPTOGRAPHIC SERVICES SSL (Secure Sockets Layer) a protocol that layers on top of TCP/IP to provide secure communications e.g., to encrypt web pages with sensitive information not cheap negotiating an SSL session can degrade server performance iSSL a cryptographic library that layers on top of the Unix sockets layer to provide secure point-to-point communications

7 NETWORK CRYPTOGRAPHIC SERVICES Ported iSSL service to the RCM2000 SSL forms a layer above TCP → easily moved from the server to other hardware use coprocessor cards for performance uses the RSA and AES cipher algorithms the RSA algorithm uses a difficult-to-port bignum package → we only ported the AES cipher (uses the Rijndael algorithm ) only implemented 128-bit keys and blocks referred to the AESCrypt implementation developed by Eric Green and Randy Kaelber

8 THE RCM2000 ENVIRONMENT The RCM2000 TCP/IP Development Kit 512k of flash RAM 128k SRAM runs a 30 MHz 8-bit Z80-based microcontroller access up to 1MB through bank switching 10 Base-T network interface software implementing (TCP/IP, UDP and ICMP)

9 THE RCM2000 ENVIRONMENT Dynamic C developed along with the Rabbit microcontrollers → support the Rabbit 2000 in embedded system applications ANSI C variant support cooperative and preemptive multitasking support battery-backed variables support atomicity guarantees for shared multi-byte variables local variables → static default storage class for variables → static not support the #include → using instead #use Bit fields and enumerated types are not supported

10 PORTING AND DEVELOPMENT ISSUES Three broad classes of porting problems that demanded code rewrites the absence of certain libraries and operating system facilities Dynamic C does not provide the standard random function the protocols include timeouts, but Dynamic C does not have a timer the iSSL library makes some use of a file-system, something not provided by the RCM2000 environment writing a random function changing the program logic so it no longer read a hash value from a file final port did not implement the RSA cipher because it relied on a fairly complex bignum library that we considered too complicated to rework

11 PORTING AND DEVELOPMENT ISSUES differing APIs with similar functionality the protocol for accessing the RCM2000's TCP/IP stack differs quite a bit from the BSD sockets used within iSSL sloppy memory management memory leaks remove logging altogether to make logging write to a circular buffer rather than a file

12 PORTING AND DEVELOPMENT ISSUES Interrupts used the serial port on the RCM2000 board for debugging configured the serial interface to interrupt the processor when a character arrived In response, the system either replied with a status messages or reset the application, possibly maintaining program state to set up the interrupt from the serial port enable interrupts from the serial port register the interrupt routine enable the interrupt receiver

13 PORTING AND DEVELOPMENT ISSUES Memory not support the standard library functions malloc and free provides the xalloc function that allocates extended memory remove all references to malloc and statically allocate all variables → drop support of multiple key and block sizes in the iSSL library

14 PORTING AND DEVELOPMENT ISSUES Program structure use of high-level operating system functions such as fork that were not provided by the RCM2000 environment → restructure the program provide neither the standard Unix fork nor an equivalent of accept the socket bound to the port handles the request → connection is required to have a corresponding call to tcp listen easily increase the number of processes ( and hence simultaneous connections ) by adding more costatements → the program would have to be re-compiled

15 EXPERIMENTAL RESULTS Compared the C implementation of the AES algorithm ( Rijndael ) included with the iSSL library with a hand-coded assembly version supplied by Rabbit Semiconductor pumped keys through the two implementations of the AES cipher → faster than the C port by a factor of A variety of optimizations on the C code including moving data to root memory unrolling loops disabling debugging enabling compiler optimization → only improved run time by perhaps 20%

16 EXPERIMENTAL RESULTS Problems lack of experience with Dynamic C lack of experience with the RCM2000 platform

17 CONCLUSIONS Problems support for some hardware idiosyncrasies API for TCP/IP both differed substantially from the Unix-like behavior the service originally used the substantial difference between BSD-like sockets and the provided TCP/IP implementation the simple absence of a file-system Solutions writing substantial amounts of additional code to implement the missing library functions reworking the original code to use or simply avoid the API

18

19

20