TPR 3211 Project 1 Project Title: AES in Javacard Project ID: 221 Supervisor: Mr. Safi Uddin Moderator: Mr. Murugadoss
Introduction
One word:CHANGE
Introduction Moore’s Law: “The number of transistors that can fit in a specific area doubles every 18 months.”
Introduction DES (Data Encryption Standard) First cracked in 1997 Record held at present is 22 hours Replaced by AES (Advanced Encryption Standard) in 2001
AES Advanced Encryption Standard Originally called Rijndael Symmetric block cipher that encrypts and decrypts data in blocks of 128 bits Specifies 3 key sizes: 128, 196 and 256 bits
AES In decimal terms, this means that there are approximately: 3.4 x possible 128-bit keys; 6.2 x possible 192-bit keys; and 1.1 x possible 256-bit keys.
AES DES key are 56 bits long There are approximately 7.2 x possible DES keys There are on the order of times more AES 128-bit keys than DES 56-bit keys
AES - Cipher Pseudocode for cipher : Cipher(byte in[4 * Nb], byte out[4 * Nb], word w[Nb * (Nr + 1)]) begin bytestate[4,Nb] state =in AddRoundKey(state, w) for round = 1 step 1 to Nr – 1 SubBytes(state) ShiftRows(state) MixColumns(state) AddRoundKey(state, w + round * Nb) end for SubBytes(state) ShiftRows(state) AddRoundKey(state, w + Nr * Nb) out = state end
AES – SubBytes(state) Non linear byte substitution S-Box
AES – SubBytes(state) For example, if s 1,1 = {53}, s’ 1,1 = {ed}
AES – ShiftRows(state) Cyclic shift of bytes in rows
AES – MixColumns(state) Columns are treated as 4 term polynomial Matrix multiplication with a fixed polynomial
AES – Inverse Cipher Pseudocode for inverse cipher : InvCipher(byte in[4 * Nb], byte out[4 * Nb], word w[Nb * (Nr + 1)]) begin bytestate[4,Nb] state = in AddRoundKey(state, w + Nr * Nb)// See Sec for round = Nr - 1 step -1 to 1 InvShiftRows(state)// See Sec InvSubBytes(state)// See Sec AddRoundKey(state, w + round * Nb) InvMixColumns(state)// See Sec end for InvShiftRows(state) InvSubBytes(state) AddRoundKey(state, w) out = state end
AES – InvShiftRows(state) Cyclic shift of bytes in rows
AES – InvSubBytes(state) Non linear byte substitution S-Box
AES – InvMixColumns(state) Columns are treated as 4 term polynomial Matrix multiplication with a fixed polynomial
Smartcard vs Javacard Must communicate with a device to gain access to a display device or network Can be plugged into a reader (card terminal) or operate using radio frequencies A smartcard is a “credit card” with a “brain” in it
Smartcard vs Javacard A Javacard is a smartcard, a smartcard is not a Javacard
Javacard There is an estimated 3 billion smartcards in the world at the present moment, and all the major smartcard players have licensed Javacard Javacard is a smart card that is capable of running programs written in Java It is designed to run on 8-bit microprocessors with as little as 256 bytes of RAM (no, I didn’t leave out the K!) and 14 kilobytes of ROM It enables the first true multi-application cards, it speeds and simplifies application development in very small memory environments
Javacard
Javacard Virtual Machine Due to limited memory resources, it is not possible to fit the JVM into Javacard 3 strategies: Small JVM is introduced Javacard API is deprecated from Java API No threads, security manager, synchronization, multi- dimensional arrays, large primitive data types Split architecture Bytecode at both ends – card terminal end and Javacard end
Javacard Communication with the outside world: Application Protocol Data Unit Data package (maximum size is 255 bytes) A Javacard always waits for “Command APDU” from the reader (card terminal software) Responds with “Response APDU”
Javacard Javacard Runtime Environment Contains API classes and the JVM Responsible for: applet installation and initialisation selection and deselection APDU dispatching transaction management catching unchecked exceptions assigns AID for each applet
Javacard How does it work? Java data is compiled into bytecode and sent to card reader (card terminal driver) Reader converts bytecode into card bytecode Wraps card bytecode into data package “Select APDU” to tell the Javacard to let go of current active applet and select the new current applet JCRE in Javacard will assign new applet AID Communication by “Command APDU” and “Response APDU”
AES in Javacard Why Javacard? Smart cards provide a secure, portable platform for "any time, anywhere" computing that can carry and manipulate substantial amounts of data, especially an individual's personal digital identity The Java Card API allows applications written for one card to be downloaded "in place" into any other card The Java Card thus allows smart cards to become a general-purpose computing platform and creates a potentially huge market for application software and development -- especially for financial, telecommunications, television, and security applications
AES in Javacard Why AES in Javacard? Increasingly, physical keys are being replaced by cryptographic keys, which are typically a thousand bits in size Modern smart cards are the ideal carriers for such keys, because they have enough computing power to do the necessary encryption or decryption on-card, so that the secret key never has to leave the card One of the reasons Rijndael was chosen as AES was because of its efficiency in low memory environments
AES in Javacard Hardware Specifications:
AES in Javacard Hardware Specifications: GemPC-410 card reader GemXpresso RAD III PK IS Javacard USB to Serial converter
AES in Javacard GUI Card Terminal Application Ocean SDK (optional) Gemplus GemPC-410 Card Terminal Driver Gemplus GemXpresso RAD III PK IS Kernel Windows 98 JDK Inprise JBuilder 3.5 Card Terminal Application AES Javacard applet
AES in Javacard Software Specifications: Windows 98 JDK1.2.2 Inprise JBuilder 3.5 Gemplus GemXpresso RAD III PK IS Kernel Gemplus GemPC-410 Card terminal driver (OCF with PC/SC bridge)
AES in Javacard Solution methods: Research into the protocols, standards involved in project Implementation of an AES applet model on a Java platform Design and coding of a Javacard applet, test run on a simulation environment (Gemplus Simulation Environment) Design and coding of card terminal application Test run both Javacard applet and card terminal application
AES in Javacard Prototype development phase 1: Tested applet security sandbox with an applet to read c:\autoexec.bat
AES in Javacard After creating keystore, signing applet and specifying permission in policy file, applet can be run
AES in Javacard Prototype development phase II: Figure: splash screen of prototype
AES in Javacard Figure: encryption screen 1 of prototype
AES in Javacard Figure: encryption screen 2 of prototype
AES in Javacard Figure: decryption screen 1 of prototype
AES in Javacard Figure: decryption screen 2 of prototype
AES in Javacard Prototype behaviour: Encryption longer than decryption
AES in Javacard Implementation plan for coming trimester: Choose between OCF and PC/SC Develop Javacard applet Run Javacard applet using GSE (Gemplus Simulation Environment) simulator to determine memory requirement, implementation errors, flow of communication, etc. Develop Card Terminal Application using OCF or PC/SC platform.
AES in Javacard Conclusion: AES in Javacard is a new platform, a new method, a new thinking.
AES in Javacard
THE END Thank you for your attention