1 / 20

More about identity and authentication

More about identity and authentication. Tuomas Aura T-110.5241 Network security Aalto University, Nov-Dec 2013. This lecture shows that authentication is much more diverse field than it first seems. What is hard about authentication in a network? Protocol design?

elana
Download Presentation

More about identity and authentication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. More about identity and authentication Tuomas Aura T-110.5241 Network securityAalto 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. 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-D0-05-04-7E) • NAI for network users • IP address in the network layer (e.g. 157.58.56.101) • 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. http://www.example.org/myservice) • Email address for email users

  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 • Examples: • 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

More Related