Attacker Models for hardware or embedded security Erik Poll Digital Security Radboud University Nijmegen 1
Security-sensitive hardware: examples 2
Naive attacker model Attacks on communication channels exploiting lousy crypto or insecure protocols Protection by • 1) mathematically strong algorithms and protocols End-points regarded as black boxes • Attacker models: network, Man-in-the-Middle, or Dolev-Yao attacker • The mathematician’s view 3
Improved attacker model Attacks on communication channels or the end-points eg. exploiting software bugs in end-points Protection by • 1) mathematically strong algorithms and protocols, 2) secure software implementations Software engineer’s view 4
Embedded security attacker model Attacks on communication channel or end-points, also exploiting hardware weaknesses of end-points Protection by • 1) mathematically strong algorithms and protocols 2) secure software implementations 3) secure hardware Cryptographic operations are gray boxes that leak some info • Hardware engineer’s view 5 I. Verbauwhede, P. Schaumont
Specific threat for embedded systems Attacker can get physical access 6
Secure algorithms vs secure implementations of algorithms As we’ll see later in this course, an implementation of a ‘secure’ cryptographic primitive ( eg AES, RSA, etc) can be completely insecure on given hardware Therefore 1. Never design your own cryptographic primitives 2. Never make your own implementations of these crypto primitives Maybe the same goes for security protocols using these primitives as well... 7 I. Verbauwhede, P. Schaumont
Brainstorm 8
Brainstorm • Why do we carry so many smartcards around? • What at are the security requirements they ensure? • How w do they ensure these requirements? • Why are they ‘better’ than the alternatives?
Differences? Commonalities? 10
Differences & Commonalities • wrt functionality: – data storage: read and/or write? – processing for and maybe also • wrt security: – confidentiality – integrity/authenticity – access control • by software for and maybe also • or is that functionality? :-) 11
NB problems introduced by cryptography 1. key generation & distribution • how do we generate & distribute keys? 2. key storage • where can we safely store keys? – This is an access control problem 3. en/decryption • who do we trust to perform en/decryption? Smartcards provide a possible solution... 12
Access control vs cryptography • Access control involves • Crypto involves data functionality • Crypto can ensure integrity & • Access control can ensure non-repudiation with MACs integrity, non-repudiation & or digital signatures and confidentiality by preventing confidentiality with read and/or write access encryption • Crypto can secure data that • Access control can only are not under our control , regulate for access to • eg data on network or stored resources under our control on USB stick • Crypto still relies on access control, namely for the keys • so crypto only moves the security problem elsewhere 13
Differences? Commonalities? Both computers, but with different resources (memory, • computing power,...) + Pro smartcard: the hardware is more secure; on PC we can remove hard disk, access memory chips,... - Con smartcard: does not allow I/O to the user 14
Smartcards 15
Overview • what is a smartcard? • hardware, protocols, operating systems • attacks and countermeasures 16
What is a smartcard? 17
What is a smartcard? • Tamper-resistant computer, embedded in piece of plastic, with limited resources • aka chip card or integrated circuit card (ICC) • capable of securely – storing data – processing data • This is what makes a smartcard smart; stupid cards can store but not process • Processing capabilities vary greatly 18
Smartcard form factors • traditional credit-card sized plastic card – ISO 7816 • mobile phone SIM – cut-down in size • contactless cards – aka proximity card or RFID transponder/tag – also possible: dual interface • iButton 19
Smartcard example uses • bank cards: chipknip, new EMV creditcards • GSM SIM in mobile phone • pay TV • public transport – eg OV chipkaart in NL • health cards – eg UZI pas in NL • passports – new generation passports with biometric information stored on chip • access cards – to control access to buildings, computer networks, laptops,... 20
Smartcard example uses • RFID tags – animal or human identification – product identification (like bar codes) • road pricing • electronic number plates • TPM (Trusted Platform Modules) in PC • digital signatures – eg eNIK (elektronische Nederlandse Identiteits Kaart) 21
Classification: functionality Functional capabilities of smartcards & RFID tags can vary a lot: 1. device just reports data – read-only file-system 2. device reports data after some access control – protected (eg password-protected) file-system • read-only or read/write 3. device can take part in crypto protocol – eg for authentication Some of these cards are programmable, some have built- in functionality which you can configure but not change Which attacks can 3 withstand, that 1 & 2 can't? Replay attacks! 26
Classic use of smartcard for authentication challenge c private CPU key K response enc K (c) • If card can perform encryption, then the private key K never has to leave the card • The card issuer does not have to trust the network, the terminal, or the card holder 27
Stupid smartcards vs smart smartcards Capabilities of smartcards & RFID tags vary a lot: • Memory cards (“stupid” smartcards) – essentially just provide a file system – possibly with some access control or, simpler still, destructive (irreversible) writes as in old payphone-cards – configurable functionality hardwired in ROM • Microprocessor cards (“smart” smartcard) – contain CPU • possibly also crypto co-processor – programmable • program burnt into ROM, or stored in EEPROM • RFID tags are often like old memory cards • Focus in this course will be on microprocessor cards 28
Security requirements • integrity – of data or functionality (incl. all software) • authenticity – resistance to copying/cloning – non-repudiation – being able to prove (not being able to deny) that an action has been carried out by some party • confidentiality – of data, or of card/card holder, ie. anonymity • availability aka resistance to denial-of-service • tamper-proof • tamper- resistance • tamper-evidence NB hardly anything is tamper- proof 29
Smartcard hardware 30
Smartcard hardware • CPU • memory – volatile (RAM) and non-volatile (ROM+EEPROM) • limited I/O: just a serial port possibly: • crypto co-processor • random number generator (RNG) No clock, no power! 31
Smart card chip ROM RAM EEPROM CPU memory management unit (MMU) Clock/ Crypto Test & RNG I/O Charge coproc. Security Pump 32
CPU • 8, 16 and now also 32 bit • Steady need for more processing powers – for virtual machines & cryptography 33
Crypographic co-processor • DES, AES – DES in hardware takes same size as DES program code in ROM • for public-key crypto, ALU providing exponentation and modulo arithmetic with large numbers 34
Smartcard memory ROM • BIOS + operating system EEPROM • the smartcard's hard disk RAM • workspace Typical modern card may have 512 bytes RAM, 16K ROM, 64K EEPROM, 13.5 MHz 35
RAM • volatile aka transient memory • SRAM (static RAM) used rather than DRAM (Dynamic RAM) for lower power consumption • used for temporary data – stack – I/O buffer • typically 128 bytes to 16 Kbyte • volatile, but small permanent storage characteristics 36
ROM • permanent storage • filled during production, using ROM mask • contains OS + possibly application code • typically 8 to 512 Kbyte • Flash is coming up as replacement of ROM • optically readable after removing top layers 37
EEPROM • non-volatile aka persistent, rewritable memory • used for applications and data: – "the smartcard's hard disk“ • typically 1 to 512 Kbyte characteristics : • – slow: 1000x slower than RAM – has limited lifetime in # writes (> 10 6 ) – writing is two stage operation: erase & write – data retention 10-100 years – writing takes high power consumption • 17V, realised using charge pump 38
ROM vs EEPROM for program code Choice between program code in ROM or EEPROM has big impact on development – Program code in ROM must be suitable for mass-use – It cannot be patched or updated There has been a clear trend away from having a lot of code in • ROM towards having smaller amount of code in ROM (eg just some standard • functionality provided by libraries or OS), and all custom functionality (the “application”) in EEPROM 39
Recommend
More recommend