P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\titulka.jpg
PV204 Security technologies
Secure authentication and authorization
•Petr Švenda svenda@fi.muni.cz
•Faculty of Informatics, Masaryk University

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Overview
•Authentication and key exchange protocols
•Problems and design principles
•Authentication protocols in electronic passports
PV204 - Authentication protocols
2

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
3
| PV204 Security Technologies: JavaCard

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
SECURITY PROTOCOLS
•
4
PV204 - Authentication protocols

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Security protocols
•Security protocol = composition of cryptoprimitives
•
•“Security protocols are three line programs that people still manage to get wrong.” (R. Needham)
•
PV204 - Authentication protocols
5

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Security protocol aspects
•Entity authentication
•Key agreement, establishment or distribution
•Data encryption and integrity protection
•Non-repudiation
•Secure multi-party computation (SMPC)
•…
6
PV204 - Authentication protocols

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Basic terms
•Identification
–Establish what the (previously unknown) entity is
•Authentication
–Verify if entity is really what it claims to be
•Authorization (access control)
–Define an access policy to use specified resource
–Check if entity is allowed (authorized) to use resource
•Authentication may be required before entity is authorized to use resource
PV204 - Authentication protocols
7

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Authentication (AUTH) vs. Key establishment (KE)
•Early literature called protocols used to establish session keys as “authentication protocols”
•Authentication is also possible without session keys
–Example: Challenge-response, active authentication
•Session keys can be established without authentication
–Example: non-authenticated Diffie-Hellman
PV204 - Authentication protocols
8

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
User vs. key-oriented goals
•User-oriented authentication goals
–Entity authentication
–Strong entity authentication – fresh entity authentication
–Mutual authentication
•Key-oriented goals
–Key establishment
–Key derivation
–Implicit key establishment
–Key confirmation
–Mutual belief in the key
•
PV204 - Authentication protocols
9

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Hierarchy of AUTH&KE goals
•
PV204 - Authentication protocols
D:\Documents\Obrazky\keystablish_goals.png
Protocols for Authentication and Key Establishment By Colin Boyd, Anish Mathuria
10

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Entity authentication
•Entity = user, machine/device
•Something entity knows (password, key…)
•Something entity is (biometrics…)
•Something entity have (smartcard…)
•Multi-factor authentication
–More than one factor (password + smartcard)
–Aim to increase attacker’s cost to compromise multiple security layers (factors)
•
–
–
–
•
•
•
PV204 - Authentication protocols
11

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Protocol message components
1.Keys
–Long-term keys
–Session keys
2.Identifiers
–Protocol principals (Alice, Bob…)
3.Nonce(s)
–Random values, timestamps, counters
•Components are combined by crypto mechanism(s)
PV204 - Authentication protocols
12

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
PROTOCOLS AND ATTACKS
•
PV204 - Authentication protocols
13

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Typical models of adversary
•Adversary controls the communication
–Between all principals
–Observe, alter, insert, delay or delete messages
•Adversary can obtain session/long term keys
–used in previous runs
•Malicious insider
–adversary is legitimate protocol principal
•Attacker can obtain partial knowledge
–Compromise or side-channels
•…
PV204 - Authentication protocols
14

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Needham–Schroeder protocol: symmetric
•Basis for Kerberos protocol (AUTH, KE), 1978
–Two-party protocol (A,B) + trusted server (S)
–Session key KAB generated by S and distributed to A together with part intended for B
–Parties A and B are authenticated via S
1.A ® S: A, B, NA
2.S ® A: {NA, KAB, B, {KAB, A}KBS}KAS
3.A ® B: {KAB, A}KBS
4.B ® A: {NB, A}KAB
5.A ® B: {NB - 1}KAB
•
•
•
•
•
PV204 - Authentication protocols
15
Can you spot problem?
D:\Documents\Obrazky\question.png
Which part ensures:
Authentication
Key confirmation
Freshness
D:\Documents\Obrazky\question.png

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
N-S symmetric: Problem?
•Vulnerable to replay attack (Denning, Sacco, 1981)
•If an attacker compromised older KAB then
–{KAB, A}KBS can be replayed to B (step 3.)
–B will not be able to tell if KAB  is fresh
–Attacker will then impersonate A using old (replayed, compromised) key KAB
•Fixed by inclusion of nonce/timestamp N’B generated by B (two additional steps before step 1.)
–Bob can now check freshness of {KAB, A, N’B}KBS
•
PV204 - Authentication protocols
What is required attacker model?
D:\Documents\Obrazky\question.png
16

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
What is required attacker model?
•Able to capture valid communication ({KAB, A}KBS)
•Able to compromise older KAB
•Actively communicate with B (reply ({KAB, A}KBS)
PV204 - Authentication protocols
17
But is assumption of compromise
of old key realistic?
D:\Documents\Obrazky\question.png

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
How (not) to reason about potential compromise
•NO: all my (many) keys are in secure hardware and therefore I’m secure (no compromise possible)
–Nothing like perfect security exists
•
•YES: assume compromise and evaluate impact
–Where are sensitive keys
–How hard is to compromise them
–What will be the impact of the compromise
–Can I limit number/exposure of keys? For what price?
PV204 - Authentication protocols
18

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
What if key is compromised?
•Prevention, detection (hard), reaction
•Prevention of compromise
–Limit usage of a key
•master key ® session keys
•Use PKI instead of many symmetric keys in trusted terminals
–Limit key availability
•Erase after use, no/limited copy in memory, trusted element
–Limited-time usefulness of keys (key update)
•(Perfect) forward secrecy: Information before is secure
•Reaction on compromise
–stop using key, update and let know (revocation)
PV204 - Authentication protocols
19

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
D:\Documents\Obrazky\question.png
Needham–Schroeder protocol: asymmetric
•Simple asymmetric AUTH & KE protocol
•Designed by R. Needham and M. Schroeder (1978)
–(below is simplified version without PKI server S)
1.A ® B: {A, NA}PKB
2.B ® A: {NA, NB}PKA
3.A ® B: {NB}PKB
•
PV204 - Authentication protocols
Can you spot the problem?
D:\Documents\Obrazky\question.png
20
Which part ensures:
Authentication
Freshness
Key establishment

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
N-S asymmetric: Problem?
•
•
•
•
•
•
•
•Discovered by G. Lowe 17 years after using formal verification method/tool
PV204 - Authentication protocols
21

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Formal verification of protocols
•Negatives
•Specific attacker model
–Different attacker (e.g., side-channels) => attack possible
•Assumes perfect crypto-primitives
•Sensitive to precise specification
•Hard to express real-world complex protocols
–Search space too large
•
•Positives
•Automated process
•Prevents basic and some advanced design flaws
•Favours simple solutions
–Complexity is enemy of security
PV204 - Authentication protocols
Is formal verification
panacea?
D:\Documents\Obrazky\question.png
22

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
References
•Security Protocols Open Repository
–http://www.lsv.ens-cachan.fr/Software/spore/
•C. Cremer, Scyther tool
–https://github.com/cascremers/scyther/
•Cas Cremer’s exercise sheet
–https://www.cs.ox.ac.uk/people/cas.cremers/scyther/scyther-exercises.html
–
•
PV204 - Authentication protocols
23

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
N-S asymmetric: Fix
•Fixed by addition of B’s identity into second step
1.A ® B: {A, NA}PK(B)
2.B ® A: {B, NA, NB}PK(A)
3.A ® B: {NB}PK(B)
•
•
PV204 - Authentication protocols
24

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
AUTHENTICATED KEY EXCHANGE
•
PV204 - Authentication protocols
25

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Methods for key establishment
1.Derive from pre-shared secret (KDF)
2.Establish with help of trusted party (Kerberos, PKI)
3.Establish over insecure channel (Diffie-Hellman)
4.Establish over other (secure) channel
5.Establish over non-eavesdropable channel (BB84)
6.…
1.
•
•
•
PV204 - Authentication protocols
26

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Methods for key confirmation
•Goal: ensure that parties use same key value(s)
•Implicit confirmation by use of valid key
–E.g., MAC by session key on future message is valid
•Explicit confirmation by challenge-response
–Dedicated steps in protocol
–
–
–
•
•
•
PV204 - Authentication protocols
27
http://www.themccallums.org/nathaniel/2014/10/27/authenticated-key-exchange-with-speke-or-dh-eke/

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Diffie-Hellman key exchange
PV204 - Authentication protocols
http://www.themccallums.org/nathaniel/2014/10/27/authenticated-key-exchange-with-speke-or-dh-eke/
28
Which part ensures:
Key establishment
Key confirmation
Authentication
D:\Documents\Obrazky\question.png

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Diffie-Hellman in practice
•K is not used directly, but K’ = KDF(K) is used
1.Original K may have weak bits
2.Multiple keys may be required (KENC, KMAC)
•Is vulnerable to man-in-the-middle attack (MitM)
–Attacker runs separate DH with A and B simultaneously
–(Unless a and b are authenticated)
•Be aware of particular p and g
–If group g is widely used up to 1024b then precomputation is possible (Logjam, CCS15)
•Huge precomputation effort, but feasible for national agency
•Certain combination of g and p => fast discrete log to obtain A
–If p is really prime and g has larger order (Indiscrete logs, NDSS17)
–
•
•
–
•
PV204 - Authentication protocols
29

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Diffie-Hellman in practice
•DH can be used as basis for Forward secrecy
•DH can be used as basis for Password-Authenticated Key Exchange
•Variant of DH based on elliptic curves used (ECDH)
–ECDH is preferred algorithm for TLS, ePassport…
–ECDH is algorithm of choice for secure IM (Signal)
•
•
•
–
•
PV204 - Authentication protocols
30

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Forward secrecy - motivation
•Assume that session keys are exchanged using long-term secrets
1.Pre-distributed symmetric cryptography keys (SCP’02)
2.Public key cryptography (TLS_RSA_...)
•What if long-term secret is compromised?
I.All future transmissions can be read
II.Attacker can impersonate user in future sessions
III.All previous transmissions can be compromised if traffic was captured
•Can III. be prevented? (Forward secrecy)
•Can I. be prevented? (Backward secrecy)
•
PV204 - Authentication protocols
31

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Forward secrecy – how to achieve
•(Perfect) Forward Secrecy
–Compromise of long-term keys does not compromise past session keys
•Solution: ephemeral key pair (DH/RSA/…)
1.Fresh keypair generated for every new session
2.Ephemeral public key used to exchange session key
3.Ephemeral private key is destroyed after key exchange
•Captured encrypted transmission cannot be decrypted
•Long-term key is used only to authenticate ephemeral public key to prevent MitM
PV204 - Authentication protocols
32

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Use of forward secrecy: examples
•HTTPS / TLS
–DHE-RSA, DHE-DSA, ECDHE-RSA, ECDHE-ECDSA…
•SSH (RFC 4251)
•Off-the-Record Messaging (OTR) protocol (2004)
•TextSecure v2 ® Axolotl protocol (TextSecure app)
•TextSecure v3 now known as Signal protocol (2015)
PV204 - Authentication protocols
33

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
PASSWORD-AUTHENTICATED KEY EXCHANGE (PAKE)
•
PV204 - Authentication protocols
34

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
PAKE protocols - motivation
•Diffie-Hellman can be used for key establishment
–Authentication ca be added via pre-shared key
•But why not directly derive session keys from pre-shared instead of running DH?
1.Compromise of pre-shared key => compromise of all data transmissions (including past) => no
forward secrecy
2.Pre-shared key can have low entropy (password) => attacker can brute-force
•Password-Authenticated Key Exchange (PAKE)
–Sometimes called Escalation protocols
1.
PV204 - Authentication protocols
35

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
PAKE protocols - principle
•Goal: prevent MitM and offline brute-force attack
1.
1.Generate asymmetric keypair for every session
–Both RSA and DH possible, but DH provides better performance in keypair generation
2.Authenticate public key by (potentially weak) shared secret (e.g., password)
–And limit number of failed authentication requests!
3.Exchange/establish session keys for symmetric key cryptography using authenticated public key
4.
•
•
PV204 - Authentication protocols
36

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Diffie-Hellman Encrypted Key Exchange
37
PV204 - Authentication protocols

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Simple Password Exponential Key Exchange (SPEKE)
PV204 - Authentication protocols
http://www.themccallums.org/nathaniel/2014/10/27/authenticated-key-exchange-with-speke-or-dh-eke/
38

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
SECURE INSTANT MESSAGING
•
PV204 - Authentication protocols
39

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Off-The-Record Messaging (OTR), 2004
•Protocol for protection of instant messaging
•Perfect forward and backward secrecy
–Via use of ephemeral DH keys
–Added OTR ratcheting (new DH key for every message)
•Plausible deniability of messages
–Message MAC is computed, message send and received
–MAC key used to compute MAC is then publicly broadcast
–As MAC key is now public, everyone can forge past messages (will not affect legitimate users but
can dispute claims of cryptographic message log in court)
•
PV204 - Authentication protocols
40

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
PV204 - Authentication protocols
41

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
The Signal protocol
•State-of-the-art of instant messaging protocols
–Used in Signal, WhatsApp, Facebook Messenger, Google Allo…
•The protocol provides:
–confidentiality, integrity, message authentication,
–participant consistency, destination validation,
–forward secrecy, backward secrecy (aka future secrecy)
–causality preservation, message unlinkability, message repudiation, participation repudiation and
asynchronicity
–end-to-end encrypted group chats
•Requires (untrusted) servers
–relaying of messages and storage of public key material
–
42
PV204 - Authentication protocols
https://en.wikipedia.org/wiki/Signal_Protocol

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
The Signal protocol implementation
•3-DH with Curve25519, AES-256, HMAC-SHA256
•Authentication of users
–1) Trust on first use 2) Trusted party (PKI) 3) Fingerprint check using other channel (hex, QR
code…)
•Protection of messages
–3-DH with perfect forward secrecy and backward secrecy
–AE with deniability (MAC key later broadcast)
–Support for offline messages with future ECDH keys (ratcheting)
•Protection of metadata (no strong anonymity as e.g., Tor)
–Message delivery time and communicating parties available
–Service provider (e.g., OpenWhisperSystem or WhatsApp) may choose to keep or delete this
information
•
43
PV204 - Authentication protocols

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
The Signal protocol – group messaging
•Speaker consistency
•Out-of-order resilience
•Dropped message resilience
•Computational equality
•Trust equality
•Subgroup messaging
•Contractible and expandable group membership
•Read more details at https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
•
44
PV204 - Authentication protocols
https://en.wikipedia.org/wiki/Signal_(software)#Encryption_protocols

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
DESIGN OF PROTOCOLS
•
PV204 - Authentication protocols
45

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Design of cryptographic protocols
•Don’t design own cryptographic protocols
–Use existing well-studied protocols (TLS, EAC-PACE…)
–Don’t remove “unnecessary” parts of existing protocols
•Follow all required checks on incoming messages
–Verification of cryptograms, check for revocation…
•Don’t design and implement your own (if possible)
–Potential for error, implementation attacks…
•But more likely you will need to design own protocol than to design own crypto algorithm
–=> can actually happen J
•
PV204 - Authentication protocols
46

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Design principles (Abadi & Needham) I.
•The conditions for a message to be acted should be clearly set out so reviewer can judge if they
are acceptable.
–Documentation, diagrams, formal specification
•Every message should say what it means, message interpretation should depend only on its content.
–“This is 2nd message of SCP’02 from A to B”
–No assumptions like next random chunk number should be encrypted 2nd message because I just
received 1st message
•Mention name of principal (“Alice01”)
–Prevents (if checked) unintended parallel runs of protocol
–Prevents reflection attack
PV204 - Authentication protocols
47

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Design principles (Abadi & Needham) II.
•Be clear about why encryption is being done
–For confidentiality, not to “somewhat” ensure integrity
•When signing encrypted data, it should not be inferred that signing entity knows data content
–No knowledge of encryption key
•Be clear about properties of nonce
–random, never repeated, unpredictable, secret
–Random ® almost never repeated unintentionally
–
•
•
PV204 - Authentication protocols
48

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Design principles (Abadi & Needham) III.
•If predictable quantity is to be effective, it should be protected so that an intruder cannot
simulate a challenge and later replay the message
–Counter as challenge ® counter freshness verification necessary ® state
•If timestamps are used as freshness guarantees, then difference between local clocks at various
machines must be much less then allowable age of message
–Otherwise an attacker can replay within time window
•Key may have been used recently and yet be old and possibly compromised
–Clear session state after session end, check freshness
•
PV204 - Authentication protocols
49

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Design principles (Abadi & Needham) IV.
•It should be possible to deduce which protocol and which run of that protocol a message belongs to
including order number in the protocol
–Danger of parallel runs of same protocol
–MAC and chaining with fresh session keys prevents message mixing
•Trust relation should be made explicit and there should be good reason for its necessity.
–Less trust needed ® better security achieved
•
PV204 - Authentication protocols
50

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
ELECTRONIC PASSPORTS
AND CITIZEN ID CARDS
•
PV204 - Authentication protocols
Credit: Slides partially based on presentation by Zdenek Říha
51

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg uk_rfid
Passports of the first generation
•Electronic passport
–Classical passport booklet + passive contactless smartcard
(ISO14443, communication distance 0-10 cm)
–Chip & antenna integrated in a page or cover
•Technical specification standardized by ICAO
–Standard 9303, 6th edition
–References many ISO standards
•Data is organised in 16 data groups (DG) and 2 meta files
–DG1-DG16, EF.COM, EF.SOD
–Mandatory is DG1 (MRZ), DG2 (photo), EF.COM and EF.SOD (passive authentication)
PV204 - Authentication protocols
52

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Chip and antenna
•
PV204 - Authentication protocols
53

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Data groups
Data group
Stored data
DG1
Machine readable zone (MRZ)
DG2
Biometric data: face
DG3
Biometric data: fingerprints
DG4
Biometric data: iris
DG5
Picture of the holder as printed in the passport
DG6
Reserved for future use
DG7
Signature of the holder as printed in the passport
DG8
Encoded security features – data features
DG9
Encoded security features – structure features
DG10
Encoded security features – substance features
DG11
Additional personal details (address, phone)
DG12
Additional document details (issue date, issued by)
DG13
Optional data (anything)
DG14
Data for securing secondary biometrics (EAC)
DG15
Active Authentication public key info
DG16
Next of kin
PV204 - Authentication protocols
54

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Protocols used in ePassports I.
I.Authentication of inspection system to chip [BAC]
–Read basic digital data from chip (MRZ, photo)
–SG: Passport provides basic data only to local terminal with physical access to passport
–S: Auth. SCP, sym. crypto keys derived from MRZ [BAC]
II.Authorized access to more sensitive chip data
–SG: Put more sensitive data on chip (fingerprint, iris), but limit availability only to inspection
systems of trustworthy countries
–S: Challenge-response auth. protocol [EAC,EAC-PACE], PKI + cross-signing between trustworthy
states [EAC]
PV204 - Authentication protocols
55
SG: security goal, S: solution used

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Protocols used in ePassports II.
III.Genuine data on passport
–SG: Are data on passport unmodified?
–S: digital signatures, PKI [passive authentication]
IV.Authentication of chip to inspection system
–SG: Is physical chip inside passport genuine?
–S: Challenge-response authentication protocol [AA, EAC-PACE]
V.Transfer data between chip and IS securely
–SG: attacker can’t eavesdrop/modify/replay
–S: secure channel [EAC, EAC-PACE]
PV204 - Authentication protocols
56
SG: security goal, S: solution used

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Authorization and passports
1.Inspection terminal to read basic info from chip
2.Inspection terminal to read biometric data from chip
3.You to enter country based on chip data
•
PV204 - Authentication protocols
57

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
ELECTRONIC PASSPORTS
- MORE DETAILS
•
PV204 - Authentication protocols
58

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Basic Access Control (BAC) protocol
•Authentication&secure channel between inspection terminal and chip
–Based on symmetric crypto (3DES), similar to SCP’0x protocols
–Low computational requirements
•Problem: anyone with access to MRZ can authenticate
•Problem: MRZ has insufficient entropy
–Document number, birth date, expiration date used
–Theoretically 58/74 bits, but in practice about 32 bits
•Offline attack (eavesdrop then crack)
–Eavesdrop valid communication between chip and reader
–Brute-force attack in less then hour (232 ops, offline attack)
•Online attacks against chip (att. model: found passport)
–Significantly slower, ~20 ms for every attempt
•
PV204 - Authentication protocols
59

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
EAC – motivation
•EU passports stores fingerprints (from 2009)
–More sensitive than facial photo => better protocol needed
•Goal: not everyone with access to passport (and MRZ for BAC) should be able to read out
fingerprint
–Issuing country decides who else can access
•Stronger authentication than BAC required
PV204 - Authentication protocols
60

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Mind exercise: symmetric crypto
•What if only symmetric crypto is used?
–Every chip has own unique symmetric key
–Large number of keys in inspection terminals
–Compromise of single terminal breach security
–=> impractical and insecure => not used
•
PV204 - Authentication protocols
61
D:\Documents\Obrazky\question.png

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Extended Access Control (EAC) protocol
•Based on asymmetric cryptography (RSA/DH/ECDSA)
•Chip Authentication (CA) based on PACE protocol
–Password Authenticated Connection Establishment (PACE)
–Uses chip’s static DH/ECDSA key and terminal’s  ephemeral DH key pair (perfect forward secrecy)
–Both parties combines chip’s public static and ephemeral public key into same key K
–Keys for encryption and MAC (KENC, KMAC) are derived from exchanged K
•How can be Terminal sure of authenticity of chip’s static key?
–Signed by Issuing country
•Terminal Authentication (TA)
–Based on challenge-response protocol (RSA/ECDSA, SHA-1/2)
–Hash of the ephemeral DH key from previous step hashed with challenges
PV204 - Authentication protocols
62

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Terminal authentication I.
•Only authorized border authorities can read the secondary biometric data (fingerprints and iris)
–The inspection system must prove to the chip it is authorized
–The chip stores a trust point – root certificate
–Inspection system presents a valid certificate chain (starting from the passport’s trust point)
specifying the IS’s authorizations (e.g. to read DG3)
–Challenge-response where IS proves knowledge/access of a secret key (whose public part is
certified)
–Certificates in Card-verifiable (CV) format
PV204 - Authentication protocols
63

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Terminal Authentication II
MCj03536860000[1]
Country A
Country B
CV CA
CV CA
IS
DV
IS
...
IS
DV
IS
...
IS
DV
IS
...
IS
DV
IS
...
CV CA
Country C
Root public key of issuing country: CV CA
PV204 - Authentication protocols
64

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Terminal Authentication III
•Supported algorithms
–RSA PKCS#1 v1.5 with SHA-1 or SHA-256
–RSA PSS with SHA-1 or SHA-256
–ECDSA with SHA-1, SHA-224 or SHA-256
–Key lengths
•For ECDSA allowed 160, 192, 224, 256 bits
•For RSA allowed 1024, 1280, 1536, 2048 and 3072 bits
•In practice ECDSA is more common, key lengths 192 and 224 bit most popular, existing
implementations also support 256 and 384 bits.
•For RSA the PKCS#1 v1.5 padding is much more popular than PSS, key lengths are between 512 (test
only) and 2048 bits.
PV204 - Authentication protocols
65

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Active Authentication (AA) protocol
•Motivation: Prevent cloning of passport
–Is chip inside passport authentic?
•Passport-specific asymmetric key stored on chip
•Public key freely readable (DG15 file, hash signed)
•Authentication against terminal
–Terminal generates 8 random bytes
–Chip adds additional 8 random bytes, hash and sign
–Terminal verifies signature
•Privacy attack: terminal’s challenge is date ® signed
•PACE protocol replaces Active Authentication
PV204 - Authentication protocols
66

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
EAC Chip authentication
•Verifies the authenticity of the chip
–Replaces Active Authentication
–Improves the security of Secure Messaging
•Keys with higher entropy than for Basic Access Control (BAC)
•Diffie-Hellman key pair (passport’s chip)
–Public key and domain parameters stored in DG14
–Private key never leaves the chip
•Diffie-Hellman key pair (inspection system – IS)
–Key pair generated according to passport’s domain parameters
–Private key kept secret, public key sent to chip
•Both the parties (passport, IS) now share a secret
–The secret is used to derive the SM keys, the ability to communicate proves the authenticity of
the chip
PV204 - Authentication protocols
67

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Chip authentication II
•Algorithms supported by the EAC specification
–Diffie-Hellman (PKCS#3)
–Elliptic Curve Diffie-Hellman (ISO 15946, BSI TR-03111 )
–Both DH and ECDH popular with chip manufacturers
•DH with 1024 or 1536 bit prime
•ECDH with mostly 224 bit curves, some implementations use 256 or 384 bits
•No challenge semantics
•Coexistence of CA and AA
PV204 - Authentication protocols
68

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Passive Authentication
•Goal: are data in chip unchanged?
•The list of the hashes (SHA-1/2)
of all present data groups is digitally
signed by the issuing organisation
(Document Signer)
–State printing house, Embassy, Etc.
•The X.509 certificate of the Document Signer issued by the CA of the issuing country (Country
Signing CA – e.g. the ministry of interior) is included.
•The CSCA certificates must be exchanged bilaterally
•ICAO PKD for DS certificates, CSCA CRL and cross certificates
•Passive authentication is a mandatory security feature of all ePassports
CSCA
DS1
DS2
ePassport 1
ePassport 2
ePassport 3
PV204 - Authentication protocols
69

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Passive Authentication – the details
•The file EF.SOD contains a CMS (PKCS#7) SignedData structure (file is read and validated by
inspection system)
–The signed data is the list of hashes of the present data groups
–The DS certificate is included (ICAO optional, EU mandatory)
–Data is signed by the DS
•Signature schemes
–RSA with PKCS#1 v1.5 padding (min. 3072 bits for CSCA, 2048 bits for DS)
•E.g. Hungary, France, Spain, Portugal, Italy: RSA 4096 bit key with SHA-1
•E.g. Austria, Netherlands: RSA 3072 bit key with SHA-256
–RSA with PSS padding (min 3072 bits for CSCA, 2048 for DS)
•E.g. Czech Republic, Norway, Denmark, Japan and Australia – all with SHA-256
–DSA (not standardized for key lengths > 1024)
–ECDSA (domain parameters must be specified, min. 256 bits for CSCA, 224 bits for DS)
•E.g. Switzerland, Germany, Russia – all with SHA-1
•Message Digest algorithms (for signature schemes and hashes of Data Groups)
–SHA-1 and all SHA-2 algorithms
PV204 - Authentication protocols
70

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
How Signal and ePass compares?
•Completely different usage scenario
–Instant messaging vs. person/terminal authentication
–Frequent updates possible vs. 15 years passport validity
•Different trust relations and participants structure
–N friends vs. many partially or fully distrusting participants
–Mostly online vs. mixed offline/online (even without clock!)
•Underlying cryptographic primitives are shared
–Forward secrecy, ECDH, AES, SHA-2…
–Ratcheting and deniability not necessary for ePass
•
•
71
PV204 - Authentication protocols

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Conclusions
•Design of (secure) protocols is very hard
–Understand what are your requirements
–Use existing protocols, e.g., TLS, Signal or EAC-PACE
•Strong session keys established with weak passwords
–Password-Authenticated Key Exchange
•Electronic passport uses variety of protocols
–Interesting and complex usage scenarios
•Mandatory reading
–M. Green, Noodling about IM protocols,
http://blog.cryptographyengineering.com/2014/07/noodling-about-im-protocols.html
–M. Marlinspike, Advanced cryptographic ratcheting
https://whispersystems.org/blog/advanced-ratcheting/
–
–
72
PV204 - Authentication protocols

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
•
73
PV204 - Authentication protocols