1. More about identity and authentication
Tuomas Aura
T Network security Aalto University, Nov-Dec 2013
This lecture shows that authentication is much more diverse field than it first seems

2. What is hard about authentication in a network?
Protocol design?
Knowing how you want to talk to
Initial knowledge and trust
For authenticated key exchange, we usually need
Identifiers
Prior knowledge and trust in something
Examples:
SSL: DNS name and CA
Kerberos: username, password and authentication center
Cellular networks: IMSI and shared key on SIM

3. Identifiers

4. Network Security Part 1: The Internet
July 2004, Shanghai
Endpoint names
Authentication and integrity depend on names (identifiers)
Each protocol layer has its own way of naming endpoints:
Ethernet (MAC) addresses in the link layer (e.g. 00-B0-D E)
NAI for network users
IP address in the network layer (e.g )
TCP port number + IP address
DNS or NetBIOS name in the higher layers (e.g. smtp.aalto.fi)
URI in web pages and services (e.g.
address for users
Tuomas Aura, Microsoft Research

5. Using identifiers How are names and other identifiers allocated?
Authority, random allocation, ...
What is the scope of the identifiers and are they unique?
How does one find the owner of a name?
Data delivery, routing
Resolving name in one protocol layer to the name space of the layer below
How to convince others that this is your name?
Authentication, authorization, name ownership
Secure naming is a difficult problem and often leads to vulnerabilities

6. Prior knowledge and trust

7. Typical starting points for authentication
Prior knowledge of cryptographic secrets:
Known public keys
Shared master key
Shared weak secret, e.g. password (much harder)
Trusted third parties:
Certification authority
Online trusted third party, e.g. RADIUS or Kerberos server

8. What else could be trusted?
Secure hardware
Secure cryptoprocessor, e.g. smart card
Trusted execution environment and attestation
Secure channels
Secure offline channel
Independent channels
Location-limited channels
Human voice and video
Attempts at avoiding trust and prior knowledge completely
Opportunistic security
Self-certifying identifiers

9. Secure hardware

10. Secure cryptoprocessor
Secure hardware can store cryptographic keys  cannot be leaked by software
Examples:
SIM card
Finnish identity card (eID)
DESFire smart card, DESFire SAM
IBM 4758 cryptographic coprocessor
Trusted platform module (TPM)

11. Trusted execution environment
Isolated computing environment, typically built into the main CPU
Protects any computation from software attacks
Intel TXT, ARM TrustZone, Global Platform
Example uses:
Mobile ticketing
Storing cryptographic keys or login credentials
DRM
Remote attestation: can prove to a remote server that it is talking to an unmodified application
Possible even anonymously

12. Secure channels

13. Two-channel authentication
Authentication over two independent channels  attacker needs to compromise both
Applications:
Text messages to confirm online bank transactions
Two-factor authentication by Google, Microsoft, Facebook etc.
Two insecure channels is better than one – or are they?

14. Secure offline channel
The channel may be authentic, secret, or both
Traditional offline channels:
User or system administrator configuring secret keys
Armed courier, diplomatic mail etc.
Offline channels in device pairing:
Touching, magic wand
User-verified key exchange
User-transferred short secret or authentication code
Synchronous user input
Secret shared data from context sensing

15. Location-limited channel
Some channels are relatively secure if the attacker is not in the room at the time of the key exchange
Examples of location-limited channels:
NFC, short-distance and directional radio, Bluetooth, camera, infrared, visible light, audio
Caveats:
Audio bugs and cameras get ever smaller
Computers and phones can be used for spying
Information may leak further than you think (e.g. radio signals, displays, keyboards)

16. Human voice or video authentication
It is still difficult to spoof humans
Remember the Turing test for artificial intelligence
Examples:
Personal meeting
Cryptophone – human voice verification of the key exchange
Caveats:
Computers are getting better at processing live voice and video
Meeting a person does not guarantee they are trustworthy

17. Authentication without trust and prior knowledge

18. Leap of faith
In leap of faith, the first key exchange is unauthenticated
Secure Shell (SSH) – first introduced LoF
Opportunistic Ipsec
HTTP strict transport security (HSTS) with self-signed certicates (not allowed in RFC 6797)
Idea: attacker is unlikely to be always on the line – but is this assumption safe nowadays?
Dangers:
Leap of faith cannot be reused to recover from failure after the first authentication (e.g. changed SSH host key)
Must be started by a human user, not triggered automatically by network traffic
Resurrecting ducking model for device pairing
Device associates to the first master it sees after reset

19. Self-certifying identifiers
Public key or its hash as entity identifier
Examples:
Self-signed certificate
Cryptographically generated IPv6 addresses (CGA)
HIP host identity
Hash of the data as object identifier
Self-certifying file system
BitTorrent and other P2P systems

20. Exercises
Can you design a secure key exchange protocol for connecting home computers to each other based on:
Trusted hub device e.g. in the network gateway
User-verified key exchange
Location-limited audio channel
Leap of faith
Self-certifying identifiers
What are the weaknesses in each solution?
Learn about the Bluetooth pairing protocols
Learn about the authentication of location updates in Mobile IPv6