Implementation and Evaluation of Authenticated Encryption Algorithms on Java Card Platform

Transcription

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Implementaton and Evaluaton of Authentcated Encrypton Algorthms on Java Card Platform MASTER THESIS Rajesh Kumar Pal Brno, Sprng 2017

2

3 Declaraton Hereby I declare, that ths paper s my orgnal authoral work, whch I have worked out by my own. All sources, references and lterature used or excerpted durng elaboraton of ths work are properly cted and lsted n complete reference to the due source. Rajesh Kumar Pal Advsors: RNDr. Petr Švenda, Ph.D. Dr. Chester Rebero, Ph.D.

4 Acknowledgments Frst and foremost, I would lke to express my profound grattude and sncere thanks to my supervsors RNDr. Petr Švenda and Dr. Chester Rebero. Wthout ther gudance, support, encouragement, and fath n me, t would not have been possble to complete ths thess. RNDr. Petr Švenda taught me how to program and manage the nusances of a small embedded system such as smart card. I am ndebted to the pans he took for revewng all my codes and suggestng measures to make them elegant and fool-proof. Dr. Chester Rebero provded help on securty aspects and techncal wrtng. I am also thankful to Prof Matyas for provdng tmely-advce, encouragement, and mpartng deep-knowledge on computer securty fundamentals. I am thankful to my organzaton and Government of Inda who has gven me the opportunty to pursue Master studes at Masaryk Unversty. I express thanks to my Indan frends who accompaned me to the course at Masaryk. I am grateful to Martn Ukrop for makng our stay at Brno, a comfortable and memorable one. Rajesh Kumar Pal

5 Keywords authentcated encrypton, CAESAR, smard card, java card, embedded system, ACORN, AEGIS, ASCON, CLOC, MORUS

6 Abstract In ths thess, fve authentcated cphers namely ACORN, AEGIS, ASCON, CLOC, and MORUS from the Competton for Authentcated Encrypton: Securty, Applcablty, and Robustness (CAESAR) are mplemented and evaluated on Java card platform. The Java mplementaton usng Java Card Technology s made for each cpher. The cphers are optmsed to explot the onboard resources such as cryptographc coprocessor, RAM, EEPROM of Java card platform. The man focus of the evaluaton s authentcated cpher s tmng performance and memory requrements. Ther performance s determned through tmng measurements. The general performance of each cpher s quantfed, and compared wth one another. The results are helpful n selecton of authentcated encrypton algorthm for low compute-power, memory-constraned, embedded devces. Ths work enables avalablty of authentcated cphers on Java card.

7 Contents Lst of Fgures Lst of Tables Lst of Abbrevatons v v 1 Introducton Authentcated Encrypton Smart Cards Motvatons and Objectve Thess Contrbutons Thess Organzaton CAESAR Competton and Canddate Algorthms CAESAR Competton Canddates requrements Canddate Authentcated Encrypton Algorthms ACORN AEGIS ASCON CLOC MORUS Comparson of Selected Canddates Lterature Revew Authentcated Encrypton Schemes Authentcated Cphers on FPGA Authentcated Cphers on Java Card Implementaton of Authentcated Cphers on Java Cards Framework for Authentcated Encrypton on Java Card Java Card Smart Card Communcaton Protocol Communcaton for AE Development Tools Applet Implementaton Common Optmsaton for Java Card Applets

8 CONTENTS 4.3 Algorthm Specfc Optmsatons ACORN AEGIS ASCON CLOC MORUS Gthub Repostory of Authentcated Cphers Evaluaton of Authentcated Cphers on Java Cards Test Cases Tmng Performance Authentcated Encrypton on Java Card Software Versus Hardware Implementaton Memory Footprnt Conclusons and Future Work 29 References 30

9 Lst of Fgures 1.1 Authentcated encrypton Smart card The concatenaton of 6 LFSRs n ACORN-128 (adapted from [10]). f ndcates the overall feedback bt for the th step; m ndcates the message bt for the th step AEGIS encrypton The state update functon of AEGIS (adapted from [11]) The sponge mode for ASCON encrypton (adapted from [12]) One round of Permutaton used n ASCON CLOC authentcated encrypton MORUS encrypton The state update functon of MORUS (adapted from [15]). In Rotl xxx_yy, xxx yy s for MORUS-640 and for MORUS Java card Communcaton protocol Communcaton protocol for authentcated encrypton Tmng results of authentcated encrypton Tmng results of authentcated decrypton Comparson of CLOC usng AES n software and hardware Tme-Memory effcency matrx

10 Lst of Tables 1.1 Secret-key cryptography The recommended parameter szes for ASCON The recommended parameter szes for MORUS Comparson of selected canddates. The type of cpher s shown as stream for stream-cpher, block for block-cpher, sponge for key-less permutaton based encrypton, dedcated for encrypton structure smlar to Type-3 Festel schemes. 1 sgnfes that AEGIS s parallelzable only for encrypton, not for decrypton Memory footprnt of authentcated algorthms. * represents CLOC usng hardware AES v

11 Lst of Abbrevatons AE AEAD APDU CAESAR IOT ISA SHA-3 SSL TLS Authentcated Encrypton Authentcated Encrypton wth Assocated Data Applcaton Protocol Data Unt Competton for Authentcated Encrypton: Securty, Applcablty, and Robustness Internet of Thngs Instructon Set Archtecture Secure Hash Algorthm-3 Secure Socket Layer Transport Layer Securty v

12 v Lst of Abbrevatons

13 Chapter 1 Introducton Ths chapter presents an overvew of authentcated encrypton and smart cards. We descrbe the motvatons, objectve and contrbutons made by the thess. The chapter also presents the organzaton of ths thess. 1.1 Authentcated Encrypton Authentcated Encrypton (AE) [Fgure 1.1] or Authentcated Encrypton wth Assocated Data (AEAD) s a form of symmetrc key encrypton whch provdes confdentalty, ntegrty, and data authentcty n one go. In a sngle step, the encrypton s combned wth generaton of ntegrty-verfable tag whle decrypton s done wth ntegrty verfcaton. Confdentalty ensures protecton of nformaton by convertng nput to ndstngushable random bts, whle authentcaton guarantees orgnalty and ntegrty of data by facltatng easy detecton of any tamperng / change n the data. The unque property of authentcated encrypton s that t smultaneously provdes confdentalty and authentcaton. Most of the authentcated algorthms use block or stream cpher as a base to encrypt the data whle utlse a structure to preserve the encrypton state. The state update functon s fed wth some tweak also called authentcated data and all the nput to generate a tag whch assures authentcty. The authentcaton tag helps detecton of possble forgery attempt. It s advantageous to combne confdentalty and ntegrty assurances nto a sngle scheme. However, practcal attacks nto wdely used protocols and applcatons (ncludng Secure Socket Layer (SSL)/Transport Layer Securty (TLS)) show that securely combnng a confdentalty mode wth Plantext Secret Key Assocated Data Authentcated Encrypton Secret Message Number Publc Message Number (confdentalty) Cphertext Tag (Authentcaton) Fgure 1.1: Authentcated encrypton. 1

14 2 Introducton an authentcaton mode s challengng and error prone. Authentcated encrypton s a type of secret-key cryptography (Table 1.1) whch provdes confdentalty and ntegrty of the messages usng a shared key by sender and recever. Due to the performance advantages over publc-key cryptography, secret-key cryptography remans the hgh-performance workhorse of cryptography. The varants of secret key cryptography are:- Block Cpher: A short fxed-length message s encrypted usng the secret key shared by the sender and recever. For example, a popular block cpher AES [1] encrypts a 16-byte (128-bt) block wth a 128-bt, 192-bt, or 256-bt key. Stream Cpher: A varable-length message s encrypted usng a publc nonce and a secret key shared by the sender and recever. For example, Rabbt cpher from estream portfolo. Message-authentcaton Code: A varable-length message s reduced to an authentcator usng a publc nonce and a secret key shared by the sender and recever. Cryptographc hash functons such as Secure Hash Algorthm-3 (SHA-3) and varants of block cphers are often used to construct messageauthentcaton codes. Authentcated Cpher: A varable-length message s encrypted as well as authentcated usng a publc nonce and a secret key shared by the sender and recever. Table 1.1: Secret-key cryptography. Cpher Message length Encrypts Authentcates Block cpher Fxed Yes No Stream cpher Varable Yes No Message-authentcaton code Varable No Yes Authentcated cpher Varable Yes Yes The varous combnatons of block cphers, stream cphers, message authentcaton codes, and hash functons are used to mplement authentcated cphers. In ISO/IEC 19772:2009, sx dfferent authentcated encrypton modes (namely OCB 2.0, Key Wrap, CCM, EAX, Encrypt-then-MAC (EtM), and GCM) have been standardzed. The commonly used AE based on block cphers are Offset Codebook Mode (OCB) [2] or Galos/Counter Mode (GCM) [3]. 1.2 Smart Cards Smart cards are very attractve securty optons to securty practtoners because of t beng self-suffcent, solated and physcally-securable hardware havng small attack surface. Smart card, as shown n Fgure 1.2, s lke a mcro-computer havng

15 Introducton 3 ts processor, coprocessor, memory (transent: RAM and persstent: EEPROM), and I/O ports for nterfacng wth other devces. It often contans specal cryptographc coprocessors for AES encrypton, RSA, DH, etc. Its strength les n the fact that t can securely store secret keys and perform cryptographc operatons. These tny computers havng ther own memores and processors are wdely used n telecommuncaton as SIM (Subscrber Identty Module), payment and bankng systems as credt / debt cards, transportaton, and healthcare. A smart card does not contan ts own power supply, dsplay, or keyboard. It nteracts wth a Card Acceptance Devce (CAD) or card reader through usng a communcaton nterface, provded by a collecton of eght electrcal or optcal contact ponts, as shown n Fgure 1.2b. Smart cards are constraned embedded devces wth lmted memory and processng capablty. To make any mplementaton really useful n practce, t must be effcent n both tme and space. Optmzng algorthms for effcency on smart cards s challengng because fancy programmng constructs of full-fledged programmng languages are not supported. The memory lmtaton requres careful optmzaton lke reusng exstng memory storages. To explot processng capablty of smart cards, data reorganzatons are often requred. Further the transfer of data from computer to smart cards beng bandwdth lmted adds on to the delays. (a) Smart card ntegrated chp [4] (b) Smart card pnout [5] Fgure 1.2: Smart card. 1.3 Motvatons and Objectve Authentcated encrypton algorthms wll be the man workhorse for secret-key cryptography n future. The Competton for Authentcated Encrypton: Securty, Applcablty, and Robustness (CAESAR) [6] wll facltate a portfolo of AE cphers. The ever ncreasng use of smart cards requres that authentcated encrypton schemes are also avalable on smart cards. We expect that by portng AE on Java Card, data securty wll be enhanced on small and embedded devces. Ths work may be useful to users who are lookng for authentcated encrypton on smart cards. Further ths work may also help n analyss of selected algorthms towards selecton n fnal portfolo of CAESAR competton. The objectve of ths work s to effcently mplement authentcated encrypton algorthms, whch wll be the future work-horse for secret-key cryptography, on

16 4 Introducton Java Card. 1.4 Thess Contrbutons The key contrbutons of the thess are as follows: () Implementaton and optmzaton of authentcated encrypton schemes on Java Card. The man contrbuton of ths thess s to mplement authentcated encrypton algorthms from CAESAR competton on Java Card. () Evaluaton of authentcate encrypton on Java Card. The evaluaton and analyss of dfferent authentcated encrypton schemes provdes a far dea about ther strengths, weaknesses and opportuntes for employng each one. () Enable avalablty of selected authentcated encrypton on smart card. We enable avalablty of selected authentcated encrypton mplementatons on smart card to the world through gthub. 1.5 Thess Organzaton The thess s organzed nto the followng chapters: Chapter 1 starts wth a overvew of authentcated encrypton schemes and dscusses challenges n portng AE algorthms on Java Card. We also dscuss the objectve and contrbutons made by the thess. Chapter 2 presents an overvew of CAESAR competton for selectng a portfolo of authentcated cphers. We descrbe selected canddate algorthms used n ths thess. Chapter 3 surveys the earler work on mplementaton of authentcated encrypton on embedded platforms and n partcular, on smart cards. We lst the sgnfcant dfferences between the dfferent approaches and compare our work wth them. Chapter 4 presents our mplementaton approach and the ptfalls we faced whle portng on Java Card. Ths chapter lsts the recommended optmsatons for Java Cards. In addton, we descrbe the algorthm specfc optmsatons carred out for dfferent schemes. Chapter 5 presents the evaluaton of authentcated cphers on Java Cards. We focus on tmng performance and memory footprnt, whch are vtal for any embedded system. Chapter 6 concludes the thess and explans how ths work can be extended n the future.

17 Chapter 2 CAESAR Competton and Canddate Algorthms In ths chapter, we gve the background of CAESAR competton and descrbe the canddate authentcated algorthms that are ported to Java Cards. 2.1 CAESAR Competton CAESAR (Competton for Authentcated Encrypton: Securty, Applcablty, and Robustness) [6] s a contest to select a portfolo of authentcated encrypton algorthms that are superor over Advanced Encrypton Standard (AES) used n Galos/counter mode [2, 3] and can effcently be mplemented n software and hardware. The CAESAR contest follows the rch tradton of focused cryptography compettons. In 1997, Unted States Natonal Insttute of Standards and Technology (NIST) held the frst open competton for a new Advanced Encrypton Standard [1]. The competton receved 15 block-cpher entres. NIST selected Rjndael [7] as AES. Smlarly, n 2004, ECRYPT conducted contest to select new stream cphers [8]. Around 34 stream-cpher submssons were receved from cryptographers around the world. In 2007, NIST ntated competton for selectng a new hash standard. The contest was partcpated by 64 submssons. Fnally Keccak [9] was selected as SHA-3. Wth the call for submsson on 16 Aprl 2013, CAESAR attracted 57 submssons from more than 150 cryptographers around the world. The second round selected 30 submsson whereas only 15 submssons could made ther way n the thrd round. The fnal portfolo for authentcated encrypton s expected to be announced n Dec Canddates requrements CAESAR specfcatons requre plantext, symmetrc encrypton key, assocated data, secret message number and publc message number as nput to produce 5

18 6 CAESAR Competton and Canddate Algorthms the cphertext and accompanyng authentcaton tag. The bref descrpton of parameters are as follows. Key: Ths s the mandatory symmetrc key of fxed (generally 80, 128 or 256-bt) length. Plantext: The mandatory nput of varable-length. Assocated data: The mandatory nput of varable-length whose ntegrty must be preserved by the cpher. Publc message number: An optonal nput feld of fxed-length whose ntegrty must be retaned. Ths s bascally a nonce. Secret message number: An optonal nput feld of fxed-length whose ntegrty and confdentalty must be mantaned. Cphertext: The output of varable-length whch provdes confdentalty of data. Authentcaton Tag: The output of varable-length (mostly 128-bt) whch assures authentcty of data. 2.2 Canddate Authentcated Encrypton Algorthms We have selected fve authentcated algorthms from the thrd-round of CAESAR competton. It s our estmaton that these have potentally hgh chances to be n the fnal portfolo of the CAESAR as they are effcent on software as well as on hardware and especally attractve for smart cards. We gve a bref overvew of our selected AE canddates for mplementaton and evaluaton on Java Card ACORN ACORN [10], developed at the Nanyang Technologcal Unversty n Sngapore, s a stream cpher based authentcated encrypton algorthm. As per ts prmary recommendatons, t uses 128-bt key, 128-bt nonce, and 128-bt tag. It has been prncpally desgned to run on resource constraned envronments. It also supports hgh performance applcatons. f m Fgure 2.1: The concatenaton of 6 LFSRs n ACORN-128 (adapted from [10]). f ndcates the overall feedback bt for the th step; m ndcates the message bt for the th step. The encrypton state of ACORN-128 s 293-bt length. It utlses sx Lnear Feedback Shft Regster (LFSR) for performng lnear bt shftng of ts state. Fgure 2.1 shows concatenaton of 6 LFSRs n ACORN-128. The ntalzaton of ACORN

19 CAESAR Competton and Canddate Algorthms 7 happens wth feedng the key and IV nto the state and runnng the cpher for 1792 steps. After ntalzaton, the state s updated wth the assocated data. The encrypton s performed after processng the AD. At each encrypton step, one plantext bt s fed for updatng the state, and the plantext bt s encrypted to cphertext bt. At ths stage the cpher s run for 256 steps. The authentcaton tag s generated n the fnalzaton step. ACORN uses three man functons. Functon to generate keystream bt from the state at each step, functon to calculate the overall feedback bt at each step, and a state update functon at each step. The state update functon starts wth updatng the state usng 6 LFSRs. The keystream bt s generated n next step. Thereafter non-lnear feedback bt s generated. In the fnal phase, the 293-bt regster s shfted wth the feedback bt. The decrypton process s smlar to encrypton whereas the verfcaton process s akn to tag generaton. It s recommended that on tag verfcaton falure, the cphertext and newly generated tag should not be gven out as output AEGIS AEGIS [11], developed by researchers from Nanyang Technologcal Unversty n Sngapore and KU Leuven at Ghent, s a dedcated authentcated cpher. Dedcated cphers do not use block or stream cphers as basc buldng block, but rather t uses a message to update the encrypton state and n the process message authentcaton s acheved for free. AEGIS s constructed from AES round. AEGIS-128 passes a 16-byte message block through 5 AES rounds. AEGIS s consdered fast as t operates at half the speed of AES. As per the recommendatons, AEGIS-128 works upon 128-bt key, 128-bt nonce, 640-bt state, and 128-bt tag. It s manly desgned for hgh performance applcatons. Intalzaton Key Process Assocated Data 128 AD Encrypt M 128 Tag Generaton AD len M len IV const0 const1 State Update state State state State state State state Tag Update Update Update (64 80 bytes) Cpher Fgure 2.2: AEGIS encrypton. Fgure 2.2 shows the man stages of AEGIS encrypton. At the core of the encrypton s a state update functon. At ntalzaton stage, the key, IV and two constants are fed to ntalze the state. The assocated data s pumped nto the encrypton state to update t. The message blocks n chunk of 16 bytes are fed to

20 8 CAESAR Competton and Canddate Algorthms the state update functon. The cphertext s generated by XORng the message wth the output state of ths stage. Fnally, the tag s generated by updatng the state wth length of assocated data and message length. Specfcally, bytes 64 to 80 of state n ths stage are used as the authentcaton tag. S, 0 S, 1 S, 2 S, 3 S, 4 R R R R R m W W S S S+1, 4 +1, 0 S +1, 1 S +1, 2 +1, 3 Fgure 2.3: The state update functon of AEGIS (adapted from [11]). The AES encrypton round functon used n AEGIS s an ordnary AES round (not the last round). A message s encrypted and authentcated wth a 128-bt key and a 128-bt ntalzaton vector. The encrypton state of AEGIS conssts of 80 bytes. The 16-byte message block s fed to update the state. The logc of state update functon s depcted n Fgure 2.3. In the fgure, R ndcates the AES encrypton round functon wthout XORng the round key and w s a temporary 16-byte word. For successful decrypton and verfcaton process, the exact values of key sze, IV sze and tag sze should be known. Smlar to encrypton, the decrypton also starts wth ntalzaton and followed by processng of assocated data. The cphertext s decrypted n the next stage. The fnalzaton stage outputs the plantext. It s recommended that the cphertext and newly generated authentcaton tag should not be provded as output f the verfcaton fals ASCON ASCON [12], developed at the Unversty of Technology n Graz, Austra, ams to mplement a moderate speed cpher wth sde-channel resstance features. ASCON s founded on duplex sponge modes, smlar to MonkeyDuplex [13]. The sponge operates on a state of 320 bts, wth njected message blocks of 64 or 128 bts. The encrypton process s splt nto four phases, shown n Fgure 2.4: 1. Intalzaton: The state s updated wth the key K and nonce N. 2. Assocated Data Processng: The state s updated wth assocated data blocks. 3. Plantext Processng: The plantext blocks are njected nto the state and cphertext blocks are extracted. 4. Fnalzaton: The key K s njected agan and extracts a tag T for authentcaton.

21 CAESAR Competton and Canddate Algorthms 9 A 1 A s P 1 C 1 P t 1 C t 1 P t C t r r r IV K N 320 p a c p b c p b c p b c p b c p a k T 0 K 0 1 K 0 K Intalzaton Assocated Data Plantext Fnalzaton Fgure 2.4: The sponge mode for ASCON encrypton (adapted from [12]). There are two recommended parameters for ASCON, shown n Table 2.1. Both versons offer 128-bt confdentalty, ntegrty and authentcty. Table 2.1: The recommended parameter szes for ASCON. Name Key-sze Block-sze Publc message Tag-sze Rounds begn Rounds number sze and end datablock ASCON ASCON-128a The nternal state of ASCON s 320 bt arranged n fve sub-states of 64-bt each. It s memory-effcent as no other storage s requred. After the ntalzaton, the AD and plantext are processed n 64-bt blocks n ASCON-128 (whch s mplemented n ths thess). The AD and plantext are packed nto block length by paddng wth a sngle 1" bt followed by zeros. Due to smaller szes of ntalzaton data and keys, more rounds are used for these phases. The data processng phase has less rounds due to abundance of nput data fed to t. The encrypton state s XORed wth data to transt the state to next stage. The state passes through a number of rounds, whch fnally generates cphertext. Round Constant Staten Substtuton Layer Lnear Dffuson Layer Stateout Fgure 2.5: One round of Permutaton used n ASCON. Fgure 2.5 shows one round of the permutaton of the ASCON cpher. Each round conssts of three operatons two XORs, a S-box and a shft operaton, thus forms a short crtcal path. In one permutaton, rounds between 6 and 12 are repeated. The decrypton mode s smlar n structure of encrypton. Unlke encrypton, the cphertext block s drectly nserted n the permutaton functon whle decrypton. The XOR between ths block and the state yelds the plantext whch s the output. Therefore encrypton and decrypton can be acheved from a sngle

22 10 CAESAR Competton and Canddate Algorthms mplementaton wth a small addtonal logc. ASCON s fast and lghtweght n hardware and software. Beng nverse-free, same code can facltate encrypton as well decrypton. ASCON s effcent for short messages and long messages by employng dfferental number of rounds CLOC Compact Low-Overhead CFB (CLOC) [14], developed at Nagoya Unversty Japan, s provably secure authentcated encrypton scheme whch uses blockcpher modes of operaton. CLOC bulds over the prevous schemes namely CCM, EAX, and EAX-prme by reducng the overhead over the block cpher, and optmsng the precomputaton complexty and the memory requrement. The block dagram of CLOC s shown n Fgure 2.6. Its man components are a hash functon (HASH), an encrypton engne (ENC), and a pseudo random functon (PRF). The HASH and PRF functons are varants of CBC-MAC. The ENC block uses AES encrypton n CFB encrypton mode. For processng the assocated data and cphertext CBC- MAC s called twce whereas cphertext s generated by a sngle call to CFB mode. It works wth two state blocks (.e. 2n bts). The tweak functons are used to update the nternal state at several ponts n the encrypton and the decrypton. Tweak functons consst of word-wse permutatons and XOR s. Message Key K K V ENC Cpher Nonce HASH V V PRF Tag Assocated Data K Fgure 2.6: CLOC authentcated encrypton. CLOC s sutable for handlng short nput data on embedded devces. To optmze the performance for small devces, the algorthm completely elmnates bt-wse operatons. CLOC wth AES on Intel Haswell famly shows a performance of 4.56 cpb, whch s consdered effcent. CLOC s provably secure up to the standard brthday bound. It guarantees prvacy aganst nonce-respectng adversares. The authentcty s ensured aganst nonce-reusng adversares MORUS MORUS [15], developed at the Nanyang Technologcal Unversty n Sngapore, ams to be fast n hardware and software by keepng a short crtcal path for the

23 CAESAR Competton and Canddate Algorthms 11 encrypton. MORUS has 3 dfferent recommended parameters whch are shown n Table 2.2. In ths thess, MORUS-640 s mplemented on smart card. Fgure 2.7 shows hgh-level vew of encrypton. Intalzaton Assocated Data Plantext Fnalzaton AD 128 M 128 AD len Mlen IV Key State Update state State Update state State state State state Tag Update Update Generator Tag const0 const1 Key Output Generator Cpher Fgure 2.7: MORUS encrypton. Table 2.2: The recommended parameter szes for MORUS. Name Key-sze IV State Tag-sze MORUS MORUS MORUS MORUS has a 2-dmensonal state array that s at the centre of the algorthm. MORUS has long ntalzaton and fnalzaton phases. MORUS uses a scheme smlar to a type 3 Festel scheme to update ts state [16]. The mult-block state s updated usng a round functon over number of rounds usng a state update functon whch s shown n Fgure 2.8. The cphertext s generated by XORng the nternal state wth the plantext to acheve confdentalty. The state update functon s njected wth the plantext to generate the tag whch assures authentcty and ntegrty. The nternal state s made up of 5 blocks of 128-bt, makng a total of 640 bts. It requres another 128-bt storage to hold the nput durng fnalzaton. As a result, MORUS has small memory footprnt. The encrypton starts wth ntalzaton of state. The AD and plantext are nserted n the state update functon n 128-bt blocks. The last block s padded wth zeros to make t full 128 bts. The decrypton s smlar to encrypton mode. The cphertext s processed n the same way as the plantext (n encrypton), and then ths plantext s fed as nput to the state update functon. The ntalzaton and fnalzaton stages requre 16 and 8 teratons respectvely to acheve strong 128-bt securty. The state update functon s based on type 3 Festel scheme [17]. It has 5 rounds that use XOR, shft and AND operatons. It heavly uses rotaton functon by splttng 128-bt nto smaller parts of 32-bt. The amount of cyclc rotaton s

24 12 CAESAR Competton and Canddate Algorthms dependent on the current round. The analyss of MORUS shows that t provde strong securty [18]. S 0, 0 S 0, 1 S 0, 2 S 0, 3 S 0, 4 Rotl _ xxx _ yy( S 0,0, b0 ) w 0 S 1, 0 S 1, 1 S 1, 2 S 1, 3 S 1, 4 m Rotl _ xxx _ yy( S 1,1, b1 ) w 1 S 2, 0 S 2, 1 S 2, 2 S 2, 3 S 2, 4 m w 2 Rotl _ xxx _ yy( S 2,2, b2 ) S 3, 0 S 3, 1 S 3, 2 S 3, 3 S 3, 4 m w 3 Rotl _ xxx _ yy( S 3,3, b3 ) S 4, 0 S 4, 1 S 4, 2 S 4, 3 S 4, 4 m w 4 Rortl _ xxx _ yy( S 4,4, b4 ) S 1 0,0 S 1 0,1 S 1 0,2 S 1 0,3 S 1 0,3 Fgure 2.8: The state update functon of MORUS (adapted from [15]). In Rotl xxx_yy, xxx yy s for MORUS-640 and for MORUS-1280.

25 CAESAR Competton and Canddate Algorthms Comparson of Selected Canddates The CAESAR canddates can be classfed on a number of parameters [16]. We consder the followng parameters to classfy our selected canddates. Parallelzable: It means the encrypton or decrypton of a block can be done ndependent of any other block. Onlne: The encrypton or decrypton of a block depends on ts prevous blocks only.e., the th block depends on 0, 1,..., ( 1) blocks. Inverse-Free: Ths parameter mples that underlyng prmtve s nverse operaton s not requred.e., encrypt functon s suffcent for encrypton as well as decrypton. Intermedate Tag: The ntermedate authentcaton tag helps to detect early f parts of a decrypted message are nvald. Robustness: An algorthm s robust f t provdes securty n both noncemsuse and decrypton-msuse settngs. Table 2.3: Comparson of selected canddates. The type of cpher s shown as stream for stream-cpher, block for block-cpher, sponge for key-less permutaton based encrypton, dedcated for encrypton structure smlar to Type-3 Festel schemes. 1 sgnfes that AEGIS s parallelzable only for encrypton, not for decrypton. Cpher Type Parallelzable Onlne Inverse-Free Intermedate Tag Robustness ACORN stream AEGIS dedcated 1 ASCON sponge CLOC block MORUS dedcated

26 Chapter 3 Lterature Revew In ths chapter, we survey dfferent authentcated encrypton schemes and the work on mplementaton of authentcated cphers on embedded systems. Smart cards beng a type of embedded system, the survey provdes an overvew on the recent work done n ths area. 3.1 Authentcated Encrypton Schemes Bogdanov et. al evaluates performance of block cpher modes of operaton for AE n parallel software [19]. The paper proposes the schedulng of multple messages n parallel to speed up both nherently sequental modes and to the scenaro of havng many but shorter messages. Sgnfcant speed-ups for seral modes as well as parallelzable modes s acheved. The frst optmzed AES-NI mplementatons for the AE modes OTR, CLOC, COBRA, SILC, McOE-G, POET and Julus are also provded. Correct authentcated decrypton requres the recever to buffer the decrypted message untl the authentcty check has been performed. In hgh-speed networks, whch must handle large message frames at low latency, ths behavor becomes practcally nfeasble. To overcome ths, Abed et. al proposes ppelneable onlne cphers, that combnes a block cpher and a famly of hash functons, as a practcal alternatve to AE schemes [20]. Onlne cphers encrypt an arbtrary number of plantext blocks and output cphertext blocks whch only depend on the precedng plantext blocks. All onlne cphers proposed so far are essentally seral, whch sgnfcantly lmts ther performance on parallel archtectures such as modern general-purpose CPUs or dedcated hardware. Andreeva et. al propose parallelzable onlne cphers, that s fully parallelzable n both encrypton and decrypton [21]. Basel Alomar proposed an authentcated encrypton scheme [22]. By advancng the hashng phase before block cpher encrypton, a hashng functon that s not unversal can be used wthout affectng securty of authentcaton. Snce the hash functon does not have to be unversal, t can be computed faster than unversal hash functon. The paper shows that hashng the plantext nstead of the cphertext can secure the hashng keys aganst key recovery attacks. 14

27 Lterature Revew Authentcated Cphers on FPGA Homsrkamol and Gaj provde the frst hardware mplementaton of AEZ on Xlnx Vrtex-6 FPGA [23]. The paper brngs out that mplementng AEZ, contrary to t s name AE made Easy, s sgnfcantly dffcult on hardware because AEZ s complex, optmzed for software, and mpossble to mplement n a sngle pass. Saarnen mplemented WhrlBob and Keyak AE on FGPGA fabrc of Xlnx Zynq 7010 [24]. The AE s realzed as a coprocessor and ntegrated wth Systemon-Chp (SoC) smlar to Cortex-A9 CPU. By offloadng authentcated encrypton on a dedcated hardware, am s to extend battery lfe and performance of the moble devce such as smart phones, tablets, and Internet of Thngs (IOT). Mchael Fvez provdes energy effcent hardware mplementatons of CAESAR submsson [25]. Joltk, MORUS, and ASCON algorthms were bult on Spartan 6 FPGA board and evaluated for energy consumpton and area requrements. The thess shows that MORUS s fastest, followed by ASCON and then Joltk. However area wse Joltk s the most space effcent, followed by ASCON and MORUS. Groβ et. al present hardware mplementatons of ASCON whch s sutable for RFID tags, Wreless Sensor Nodes, Embedded Systems [26]. They show that ASCON s fast and small as well as can also be easly protected aganst dfferental power analyss attacks. They present three varants wth dfferent desgn goals mplemented n VHDL and evaluated usng a Cadence-based ASIC desgn-flow. Kotegawa et. al performed hardware mplementatons of authentcated cphers wth VIVADO Hgh-Level Synthess whch s a tool of Xlnx [27]. The paper shows varous optmzaton technques on the pont of speed, area sze and the clock frequency. They work on two nonce-based algorthms (AES-OTR and SILC) and two Nonce-msuse Resstant algorthms (AES-COPA and POET). Jasper Gorssen evaluates three CAESAR canddates (Trva-ck, Ketje and MORUS) on FPGA [28]. They chose area and speed as the optmsaton targets. They show that Ketje has the smallest area usage and MORUS has an excellent speed/area rato whereas Trva-ck, whle havng good throughput n the speed optmsed verson, underperforms n area usage compared to others. 3.3 Authentcated Cphers on Java Card On Java Card Platform, Classc Edton 3.0.5, javacardx.crypto.cpher package provdes the AEADCpher class whch s the abstract base class for authentcated encrypton wth assocated data cphers [29]. Examples of AEAD algorthms are the GCM and CCM modes of operaton for AES. AEAD cphers can be created by the Cpher.getInstance method usng the ALG_AES_GCM and ALG_AES_CCM algorthm constants. The returned Cpher nstance should then be cast to AEAD- Cpher. Besde GCM and CCM modes of AES support on Java card, we could not fnd any other authentcated encrypton algorthm on Java card. To the best of our knowledge, ths work s the frst attempt to provde fve authentcated encrypton from CAESAR submsson on Java card platform.

28 Chapter 4 Implementaton of Authentcated Cphers on Java Cards Ths chapter descrbes framework for development of authentcated cphers on Java Card. The mplementaton detals and algorthm specfc optmsatons done for each cpher n makng them sutable for Java Card are also descrbed. 4.1 Framework for Authentcated Encrypton on Java Card Ths secton gves an nsght nto Java Card, the APDU based communcaton protocol, and the protocol we mplemented for authentcated encrypton. The development tools are lsted and we also descrbe the general optmsatons for Java Cards. ROM (76 KB) Operatng system Communcaton Securty (AES, RSA) CPU 8 bt 5 MHz Optonal (Crypto coprocessor) RAM 4 KB EEPROM(128 KB) Flesystem Program Fle Keys Passwords Applcatons Fgure 4.1: Java card Java Card Java Card 1 [30] refers to a software technology that allows Java-based applcatons (applets) to be run securely on smart cards and smlar small memory footprnt devces. Java Card s the tnest of Java platforms targeted for embedded devces. 1 In ths thess Oracle SDK: Java Card Development Kt s used 16

29 Implementaton of Authentcated Cphers on Java Cards 17 Java Card gves the user the ablty to program the devces and make them applcaton specfc. It s wdely used n SIM cards (GSM moble phones) and ATM cards. Fgure 4.1 gves an nsght nto the CPU capablty and memory szes of Gemalto Java Card. The GlobalPlatform specfcatons are used for the secure management of applcatons on the card (download, nstallaton, personalzaton, deleton) Smart Card Communcaton Protocol The communcaton between a smart card and a computer follows a well defned communcaton protocol shown n Fgure 4.2. The communcaton happens n form of data packages called Applcaton Protocol Data Unt (APDU) 2 whch contan ether command or response messages. Communcaton model s master/slave n whch smart card s slave and computer s master. The smart card (attached to a reader) always wat for a command APDU from host computer, processes as per the receved command and returns result n a response APDU. PC Master Command APDU Response APDU Smart Card Slave Fgure 4.2: Communcaton protocol Communcaton for AE The communcaton protocol realzed for mplementaton of all authentcated encrypton s shown n Fgure 4.3. To start nteracton wth the Java Card, the host computer starts by selectng an Applet. On successful selecton, the host communcates the secret key, assocated data and other parameters requred as per CAESAR specfcatons. For the sesson, the key s stored securely on the card. Thereafter nput s packeted nto APDU frames and submtted to the Java Card for encrypton. The output cphertext for encrypton process and plantext for decrypton process, s returned for each submsson Development Tools The development nfrastructure s buld on Macbook pro wth OS X The followng software are nstalled: 1. JDK 1.8.0_73 and Netbeans 8.1 IDE: NetBeans s a software development platform that helps applcatons development usng Java. 2 APDU protocol s an applcaton layer standard and ts specfcatons are gven n ISO

30 18 Implementaton of Authentcated Cphers on Java Cards Host Computer Java Card Select Applet (command APDU) Ack Selecton (response APDU) Key & Assocated Data (command APDU) Ack Key Recept (response APDU) Input Data (command APDU) Output Data (response APDU) Fgure 4.3: Communcaton protocol for authentcated encrypton. 2. Apache-ant 1.9.6: Apache Ant s a software tool for automatng software buld processes. 3. Applet Playground: AppletPlayground s an educatonal repostory for gettng to know JavaCard development by learnng from exstng open source software. 4. Global platform Pro v0.3.7: GPShell s a scrpt nterpreter that talks to a smart card whch comples to the GlobalPlatform Card Specfcaton. It s wrtten on top of the GlobalPlatform Lbrary. It uses the PC-SC Connecton Plug-n for accessng smart cards. It can establsh a secure channel wth a smart card, load, nstantate, delete and lst applcatons on supported smart cards. 5. PCSC lte: PC/SC s the nternatonal standard for PC to smart card reader communcaton, whch s mplemented by PCSC-Lte Applet Implementaton The natve algorthm and source code n C has been provded by the nventors of the respectve authentcated cphers. We mplement the algorthms n Java and test byte-level compatblty of our output wth the results produced by natve C source code. We then modfy our code and test wth Java Card smulator. On successful executon wth the smulator, we prepare the code for portng on real Java Card. We port our Java mplementatons on Java Card and measure the tme taken to fnd out effcency of our mplementatons. We also measure the memory footprnt of each cpher. We optmse the mplementatons to mprove upon the tmng or to reduce the memory consumpton.

31 Implementaton of Authentcated Cphers on Java Cards 19 A man applet class (e.g. AEGISApplet.java) along wth the supportng classes (e.g. AEGISCore.java) are prepared. The core class contans the algorthmc mplementatons. The constructor of applet declares varables, ntalses varous methods and keep them ready for subsequent use. The nstall method nstalls the applet. The select and deselect methods are used to clean up mportant parameters such as key. We defne two new nstructons (e.g. INS_AEGISEncrypton (0x61) and INS_AEGISDecrypton (0x62)) respectvely for encrypton and decrypton functons of authentcated cphers. To cater to encrypton nstructon a dedcated encrypton method (e.g. AEGISEncrypton) s created whch does the followng: 1. Copy the message (plantext) from APDU buffer to fast RAM memory byte array. 2. Call Core class (e.g. AEGISCore.java) for encrypton. 3. Copy back the cphertext from RAM memory to APDU buffer. 4. Return the encrypted bytes to the host applcaton. The decrypton nstructon calls the decrypton (e.g. AEGISDecrypton) method to perform the followng steps for decpherng: 1. Copy the cphertext from APDU buffer to fast RAM memory byte array. 2. Call Core class (e.g. AEGISCore.java) for decrypton. 3. Copy back the plantext from RAM memory to APDU buffer. 4. Return the decrypted bytes to the host applcaton. We also prepare the user program that runs on the PC. Ths program acts as a nterface between the smart card and the users. It receves nstructons and data from users and communcates wth smart card usng APDU packets. The APDU packet has a header of 5 bytes followed by the payload. The max sze of APDU s 256 bytes. Dfferent types of APDU can be send by properly settng up the header felds and ts nterpretaton on the card. Ths functon performs the followng: 1. Uses cardmanager to connect to the card. 2. Selects an applet (e.g. AEGISAPPLET) usng cardmanger. 3. Prepares APDU for sendng data wth requred headers. 4. Receves user nput regardng mode (encrypton or decrypton) and the fle to transform. 5. Read fle and prepare for encrypton/decrypton by dvdng ts data nto packet szes of 232 bytes payload for encrypton and 248 bytes payload for decrypton. For decrypton the last 16 bytes carres the authentcaton tag used n verfcaton. 6. Pads the last payload to a multple of 16 bytes.

32 20 Implementaton of Authentcated Cphers on Java Cards 7. Measures tmngs for encrypton and decrypton. The class fle named CardMngr.java has the code for connectng/dsconnectng a smart card to the PC. It also has methods for sendng the APDU to the smart card. 4.2 Common Optmsaton for Java Card Applets Java Card platform s a constraned devce whch does not support Uncode characters, 32-bt and 64-bt ntegers, float and double data types, threads, and multdmensonal arrays. Based on the experence of ths work and gudance gven at [31, 32], we lst the common optmsatons that are generally appled on Java Card Applets. We have appled these best practces n our mplementatons. Allocaton and Intalsaton of objects n constructor versus methods at the tme of call: The allocaton and default ntalsaton of objects (memory arrays, keys, pns, cphers, etc.) n constructor when a card s nstalled s a good optmsaton as t allocates memory and keep the objects ready for usages. Ths s much more effcent than creatng the objects when requred as tme gets wasted. It s recommended to ext the process f all requred resources are not allocated. Reusng objects: Most of the Java Card Runtme Envronments do not contan garbage collector. Therefore any object nstantaton usng new permanently consumes the storage space as t can never be reclamed due to absence of garbage collecton. Reusng objects s a necessty to have best usage of scarce memory resource. The care should be taken to reduce the sde-effects of reusng objects by proper ntalzaton before reuse. Memory allocaton: There are two types of memory on Java card RAM and EEPROM. The RAM s transent whereas EEPROM s persstent. EEPROM s consumed to allocate memory for objects created usng new, and all global varables of basc types (byte, short). RAM s consumed for allocatng memory for local varables, parameters of methods, and and objects created wth Java card system call such as JCSystem.makeTransentByteArray. Generatng and keepng the key on card versus transferrng key from host: The smart card s capable of generatng and securely storng secret keys. It s much better from securty and performance perspectve to generate and keep the key on the smart card rather then transferrng the key from host. However the use case of an applcaton may nfluence ths decson. Senstve data must be stored n transent memory wth ntalzaton at the begnnng and clearance at the end of the sesson. Workng data stored on RAM not on EEPROM: Workng data must be stored on transent RAM. Keepng data on EEPROM s slow (sometmes 1000 tmes slower than RAM) as well as not recommended from securty perspectve as t remans persstent (may be done wth due thought and addtonal protecton lke encrypted wth PIN) on card.

33 Implementaton of Authentcated Cphers on Java Cards 21 No object creaton n Applet: In the nterest of effcency, all objects must be created n constructor but not n other functons n the Applet. The constructor s called once resultng n memory allocaton once only. A careless allocaton of memory n a local method used frequently results n memory wastage as unclamable memory chunks get allocated. Copy-free methods: Copy-free methods are faster than copy based methods and recommended to be used on memory constraned smart cards. Payload sze: The payload sze decdes the amount of data transferred to the smart card n one APDU. The max sze of an APDU s 256 bytes. The maxmum payload sze may be used to pack the headers and data to save on the communcaton tme. Constants: Usng the qualfers statc and fnal to a varable n Java makes t constant. The use of constants result n smaller program sze and better performance. Avod storng ntermedate values: The use of compound arthmetc statement n program saves memory whch otherwse gets consumed wth multple separate assgnments. 4.3 Algorthm Specfc Optmsatons ACORN ACORN s a stream cpher based authentcated encrypton algorthm. Though t has been desgned for resource constraned embedded envronment, we found t to be one of the msft for Java Card platform. ACORN converts all bytes of nput message to bts, stores each bt n a byte and performs heavy bt shft operatons. As bt shft operatons are extremely slow on Java Cards, we receved extremely poor tmng performance. The tmng results can be mproved on the platform whch have ISA support for bt shft operatons. Due to no drect support for bt shft operatons on Java Card, optmsaton mprovng tmng results s not possble AEGIS AEGIS s a dedcated authentcated encrypton algorthm that uses AES round for ts constructon. The followng optmsaton n memory s carred out. Memory Optmsaton: To mprove upon the performance of AEGIS, lookup arrays are used for AES operaton. There are 4 arrays (TE[0]...TE[3]) each of 1024 bytes. These are read-only arrays.e., wrte-once read-multple tmes. Due to shortage of RAM memory on Java Card t could not be buld on the RAM. Further consderng the fact that EEPROM has large sze and read operatons are effcent on t, the lookup arrays are allocated wth memory space on EEPROM. Intally t created a bg sze (37 KB) cap fle whch could

34 22 Implementaton of Authentcated Cphers on Java Cards not be uploaded on the Java Card. We found that the cap fle occupes too much of EEPROM causng the upload to fal. To mtgate ths problem we modfed the qualfer of lookup arrays to prvate fnal statc as a result the compler consdered the elements of arrays as constant and the space got saved. In addton to ths, we also reused a few varables to save on the memory consumpton. The resultng cap sze reduced to 12 KB and uploaded successfully ASCON ASCON has sponge-based mode of operaton wth custom-talored SPN permutaton. The sponge (keyless permutaton) operates on a state of 320 bts, wth njected message blocks of 64 or 128 bts. ASCON uses heavy bt manpulaton n ts operatons. We optmsed bt rotaton as t was becomng a major performance kller. Cyclc bt rotaton: In the permutaton functon, rght cyclc bt rotaton s requred. In the natve code, the bt rotaton was done at nteger level. As ntegers are not supported on Java card Technology, we realzed cyclc bt rotaton by manpulaton at bt level. Whle t worked correctly, we fnd t adds extensve delay as each bt n nput data undergo manpulaton. Therefore, we optmzed our mplementaton for achevng cyclc bt rotaton as combnaton of left and rght shft at byte level, whch mproved the performance CLOC CLOC uses state, a 16 byte array, to keep the state of encrypton. For the core encrypton, t uses AES. The state passes through 3 stages sequentally Assocate Data processng, Nonce processng, and Message processng. The tag and cphertext are derved out n the process. The followng two are optmsed to mprove performance. CTX Structure: The CTX structure of CLOC keeps the context nformaton at all tmes. Ths structure uses ponters to track memory arrays. The CTX s fed wth assocated data, nonce, and message to generate the cphertext and the tag. We smplfed the CTX structure to store requred data n sngle dmenson arrays. XOR operaton: In CLOC the XOR operates at nteger level. We modfed the XOR operaton to operate at byte level. In addton, all varable of type long are declared as byte array of sze 8. The block structure s also smplfed as byte array of sze MORUS MORUS s a dedcated authentcated cpher. The desgn of MORUS makes t parallelzable. The core of MORUS s the state update functon whch updates

35 Implementaton of Authentcated Cphers on Java Cards 23 the state of the cpher. In each step of MORUS, there are 5 rounds wth smlar operatons to update the state. MORUS heavly uses bt rotaton for dffuson. The AD, and nput data are operated on the state n a phased manner. The endanness of the nput parameters s corrected before further processng. The followng optmsatons undertaken for MORUS. 2D state array as 1D array: MORUS authentcated encrypton uses a 2- dmensonal state array for ts core functon. The state s organzed n 5 blocks of 128-bt each, totallng a total of 640-bt. As 2-dmensonal arrays are not supported on Java card Technology, we converted the structure of state nto 1-dmensonal array. We changed the state update functon and other methods to accommodate the new structure of state. Cyclc bt rotaton: The state update functon performs XOR, AND and cyclc bt rotaton operatons. The cyclc bt rotaton s generally mplemented usng btwse shft operators. In the natve mplementaton of C reference code, the state update functon uses shft operator on ntegers to effect cyclc bt shft by predefned constants. But as ntegers are not supported on Java card Technology we had to manpulate 4 consecutve bytes to effect a shft n an nteger. The nave mplementaton of cyclc bt rotaton by manpulatng each bt was found to be very expensve n terms of tme. Therefore we mplement cyclc bt rotatons as combnaton of left and rght shft at byte level. We also encountered error n cyclc rotaton of negatve numbers. The error occurred because byte (8-bt) s upgraded to nteger (32-bt) n Java before shft, and 2 s complement (of negatve number) adds 1s n all MSB bts for negatve numbers. Ths we resolved usng logcal rght shft (>>>) and by ANDng wth sutable constants. Endanness Issue: The reference C mplementaton uses lttle-endan to represent the data. Java s bg-endan by default.e., t stores hgh-order bytes of a word at MSB places. To have byte-level compatblty wth outsde world, we manual convert byte-orderng of words. We change the endanness of nput data manpulate t as per MORUS algorthm and re-change the endanness before delverng the output. 4.4 Gthub Repostory of Authentcated Cphers A repostory on gthub wth the ttle Authentcated Encrypton on Java Card [33] s created that contans the source of the authentcated cphers ported on Java card platform. Ths enables avalablty of authentcated cphers on Java card to the publc.