BUSLab_cmyk kopie2
www.buslab.org
Masaryk U., Monet+ 8.3.2013
White-box attack resistant cryptography – mobility tickets
Petr Švenda
svenda@fi.muni.cz
Masaryk University, Brno, Czech Rep.

www.buslab.org
Replace smart card by whitebox transform?
lOnly to limited extent
lLimitation of arguments size
lOperation atomicity
●one cannot execute only half of card’s operations
lNo secure memory storage
●no secure update of state (counter)
lBoth can be used as black-box
●smart card can use PIN
lBut still some reasonable usages remain
Masaryk U., Monet+ 8.3.2013

www.buslab.org
Proximity-based credentials control
lGradual authorization/credential as opposed to nothing × PIN
lMobile phone (Android) with NFC reader
lCredentials with different level of sensitivity
●available based on proximity (NFC) of tags/SC
●E.g., ISO/IEC 14443 smart cards
lPrototype implemented
●three levels of control ~ 0, 1 or 2 cards in proximity
●cryptographic key read from smart card ()
●GalaxyS3 + JCOP 4.1
●Application screen reacts to new cards
Masaryk U., Monet+ 8.3.2013

www.buslab.org
Masaryk U., Monet+ 8.3.2013


www.buslab.org
Demo – Android + NFC + SC
lPhone used: Galaxy S3, Android, NFC
●android.nfc.* (TagViewerPrivileges.java)
lCards used:
●JCOP 4.1 with simple JavaCard applet
●multiply two numbers send via APDU
●Mifare 1K, Nokia NFC tag…
●Card with “unknown” ATR (“attacker’s” card)
lOnly one card managed by NFC stack at time
●solved by adding time window
Masaryk U., Monet+ 8.3.2013

www.buslab.org
Possible directions
lCard presence (multiple)
lCard presence + key transfer
lCard presence + on-card key usage (operation)
lCard presence + on-card key usage + CEF/CED
l
lRemotely Keyed Encryption (RKE)?
l
l
l
Masaryk U., Monet+ 8.3.2013

www.buslab.org
RKE – requirements, idea
lRequirements:
●high speed encryption
●key never leaves smart card
●encryption/decryption is possible only when smart card is present
lIdea: use on-card encryption, but move heavy work to PC in secure way
●Remotely Keyed Encryption (Blaze 1996)
l
Masaryk U., Monet+ 8.3.2013

www.buslab.org
RKE call diagram
1. Initial request V1, file (in)dependent
2. Response R1 depends on V1 and key
Encrypt file with R1
Process request, save State
3. Request V2  depends on encrypted file
4. Response R2 depends on key, V2 and State
Modify file with R2
Masaryk U., Monet+ 8.3.2013

www.buslab.org
Attacker models
lBasic model (Blaze 96)
●attacker have no access to SC
●cannot create own requests
●attacker completely control PC (ops, values)
lStrong BFN model (BFN 98)
●attacker had access to SC for limited time
●was able to create own request (database)
●no access now
●
Masaryk U., Monet+ 8.3.2013

www.buslab.org
I-RaMaRK
nFirst secure mode for RKE (strong model)
nRequires 2 APDU messages
n
n
p
iramark
Masaryk U., Monet+ 8.3.2013

www.buslab.org
I1 and THCEP
nFast modes for basic attacker model
pnot inversion/forgery secure, key independent of file
nRequires only 1 APDU message
n
n
p
thcep i1
Masaryk U., Monet+ 8.3.2013

www.buslab.org
Length-Increasing RKE
n1 APDU mode for strong attacker model
prandomization nonce must be used
n
n
p
lisrke
Masaryk U., Monet+ 8.3.2013

www.buslab.org
Automatic white-box code transformation
lParse existing source code
lIdentify “transformable” operations
●suitable size of operands
●no side effects
●…
lTransform operations into white-box representation
lOr move to smart card
lUpdate existing code accordingly
Masaryk U., Monet+ 8.3.2013

www.buslab.org
Summary
lHomomorphic encryption
●Presentation only, no real R&D expectations
lWhitebox crypto
●Implementation of selected schemes planned, open-source
●Replacement for smartcards?
●Remotely-keyed encryption
lProximity-based authorization/credential control
●Master thesis, proof-of-concept
l
●
Masaryk U., Monet+ 8.3.2013