THE FUTURE OF AUTHENTICATION FOR THE INTERNET OF THINGS

Transcription

1 THE FUTURE OF AUTHENTICATION FOR THE INTERNET OF THINGS FIDO ALLIANCE WEBINAR MARCH 28,

2 INTRODUCTION TO THE FIDO ALLIANCE ANDREW SHIKIAR SENIOR DIRECTOR OF MARKETING MARCH 28,

3 THE FACTS ON FIDO The FIDO Alliance is an open, global industry association of 250+ organizations with a focused mission: Today, its members provide the world s largest ecosystem for standards-based, interoperable authentication AUTHENTICATION STANDARDS based on public key cryptography to solve the password problem 300+ FIDO Certified solutions Available to protect 3 BILLION+ user accounts worldwide 3

4 DRIVEN BY 250 MEMBERS Board of Directors comprised of leading global brands and technology providers + SPONSOR MEMBERS + ASSOCIATE MEMBERS + LIAISON MEMBERS 4

5 WHY FIDO? The World Has a Password Problem PASSWORDS Security Usability For users, they re clumsy, hard to remember and they need to be changed all the time SECURITY Weak Strong Poor Easy USABILITY 63% of data breaches in 2015 involved weak, default, or stolen passwords -Verizon 2016 Data Breach Report 65% Increase in phishing attacks over the number of attacks recorded in Anti-Phishing Working Group There were 1093 data breaches in 2016, a 40% increase from Identity Theft Resource Center,

6 WHY FIDO? OTPs improve security but aren t easy enough to use - and are still phishable OTPs Usability TOKEN NECKLACE USER CONFUSION SECURITY Weak Strong Security STILL PHISHABLE SMS RELIABILITY Poor Easy USABILITY 6

7 THE WORLD HAS A SHARED SECRETS PROBLEM 7

8 WE NEED A NEW MODEL 8

9 HOW ARE WE DOING IT? STANDARDS ECOSYSTEM DEPLOYMENTS USER EXPERIENCE 9

10 HOW OLD AUTHENTICATION WORKS ONLINE CONNECTION The user authenticates themselves online by presenting a human-readable shared secret 10

11 HOW FIDO AUTHENTICATION WORKS LOCAL CONNECTION The user authenticates locally to their device (by various means) The device authenticates the user online using public key cryptography ONLINE CONNECTION 11

12 SIMPLER AUTHENTICATION Reduces reliance on complex passwords Single gesture to log on Works with commonly used devices Same authentication on multiple devices Fast and convenient 12

13 STRONGER AUTHENTICATION Based on public key cryptography No link-ability between services or accounts Keys stay on device Biometrics, if used, never leave device No server-side shared secrets No 3 rd party in the protocol 13

14 FIDO A NEW PARADIGM: SECURITY Weak Strong authentication = STRONGER & SIMPLER Poor Easy USABILITY 14

15 FIDO-ENABLED APPS + SERVICES 3 BILLION AVAILABLE TO PROTECT ACCOUNTS WORLDWIDE 15

16 BUT WAIT 16

17 THE WORLD HAS AN IOT SECURITY PROBLEM 17

18 WE NEED A NEW AUTHENTICATION MODEL FOR CONNECTED USERS & DEVICES 19

19 THANK YOU ANDREW SHIKIAR SR. DIRECTOR OF MARKETING 20

20 THE FUTURE OF AUTHENTICATION FOR THE INTERNET OF THINGS ROLF LINDEMANN, NOK NOK LABS Thanks to this app you can maneuver the new Forpel using your smartphone! Too bad it s not my car.

21 What s the challenge Source: HP Enterprise IoT Home Security Systems 22

22 Context Secure firmware protects one healthy part from infected parts Need strong fundament, e.g. a CPU supporting ARM TrustZone, Intel SGX, etc. Focus of today s presentation Strong authentication makes sure only legitimate entities get access 23

23 Scope Cloud Services 24

24 Scope Primary interaction devices, i.e. devices a) which we typically have in our possession and b) that have a user interface Cloud Services Devices that are not primary interaction devices, e.g. smart light bulbs, WIFI routers, smart fridges, smart thermostats, connected cars, smart door locks, Addressed by FIDO & W3C Web Authentication, not the core focus of this talk 25

25 Primary Interaction Devices Primary interaction device have the capability to verify the user through their user interface. They can connect to another device or to a cloud service They can implement a FIDO Authenticator allowing the user to strongly and conveniently authenticate to devices or cloud services. Trust Execution Environments and/or Secure Elements add security. 26

26 Scope User to standalone devices Focus of this talk 27

27 Scope Cloud Services Focus of this talk User to cloud-connected devices 28

28 Scope Cloud Services Device-to-Device Authentication Device-to-Cloud Authentication 29

29 Background Attacks IoT Device IoT Device Perimeter Infected Device IoT Device IoT Device IoT Device IoT Device IoT Device Internet IoT Device IoT Device IoT Device IoT Device IoT Device IoT Device 30

30 Background 31

31 Attack Scenarios 1. Exploit firmware vulnerabilities TrustZone for ARMv8-M provides protection layers that help keeping attacks local to one software module ( enclave ). Not in focus of this talk IoT Device IoT Device Legitimate authentication 2. Enter at the front-door: Impersonate user Need Strong Authentication to protect against such attacks. Our focus. 32

32 User to Device Authentication 33

33 User to Device interaction Without keyboard and display? Device 34

34 User to Device interaction User needs some computing device with user input interface and display The Device only sees some other Device no user. How can the Device know whether there is a user and whether the other device is trusted? Without keyboard and display 1 2 Convenience: Devices want to support arbitrary user verification methods, e.g. PINs, Fingerprint, Face, - with limited computing power Security: Device could be infected, so users don t want to reveal bearer tokens (like passwords, etc.) to it IoT Device 35

35 did we see that before? TLS / DTLS or other secure channel Device See 36

36 User to Device Authentication Challenge User verification Authenticator FIDO Authentication IoT Device Require user gesture before private key can be used Private key dedicated to one app (Signed) Response Public key 37

37 First Authenticator Registration (Example) 1 Device in factory default settings state IoT Device 3 Start registration process (for first authenticator) 2 Press register button 38

38 Standalone Devices Smart Light Bulbs Cloud Services WIFI Router User to standalone devices 39

39 Devices with Cloud Dependency Cloud Dependency: We want the cloud service being able to grant access to the device to a specific user But: Do not rely on stable internet connection at time of access Thermostats Parcel Lockers Cloud Services Rental Cars User to cloud-connected devices Door locks 40

40 How does it work with central authorization infrastructure? Cloud Service Mobile App SDK 1. Traditional FIDO Registration (one-time) 2. Traditional FIDO Authentication 3. Signed JWT w/pop (FIDO Uauth) Public Key (see RFC7800) FIDO Stack Device 0. (OOB) Inject trust anchor 41

41 How does it work with central authorization infrastructure? Mobile App SDK FIDO Stack JOSE Header: { kid : 1e8gfc4, alg : ES256 } JOSE Payload: { "iss": " "aud": " "exp": , 1. Traditional FIDO Registration (one-time) 2. Traditional FIDO Authentication 3. Signed JWT w/pop (FIDO Uauth) Public Key "cnf":{ (see RFC7800) Device Cloud Service "jwk":{ "kty": "EC", "use": "sig", "crv": "P-256", "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" } } 0. (OOB) Inject trust } anchor JWS signature, computed by Cloud Service 42

42 How does it work with central authorization infrastructure? Cloud Service Mobile App SDK FIDO Stack 1. Traditional FIDO Registration (one-time) 2. Traditional FIDO Authentication 3. Signed JWT w/pop (FIDO Uauth) Public Key (see RFC7800) 4. FIDO Authentication to device with signed JWT w/ PoP (FIDO) Public Key as additional data Device 0. (OOB) Inject trust anchor 43

43 44 Gallagher Unlocks the Internet of Things with Nok Nok

44 45 Source: Philafrenzy, Wikipedia

45 46 Source: Klaus Mueller, wikipedia

46 Device to Device & Device to Cloud Authentication 47

47 Scope Device to device authentication User to device authentication 48

48 User to Device Authentication How an Authenticator verifies the user and whether it verifies the user depends on the Authenticator model and is represented in the Metadata Statement. Challenge User verification Authenticator FIDO Authentication IoT Device Require user gesture before private key can be used Private key dedicated to one RP (Signed) Response Public key 49

49 Device to Device Authentication There are Silent Authenticators, never requiring any user interaction. Challenge Authenticator FIDO Authentication IoT Device and such Authenticator might be embedded in a device (Signed) Response Public key 50

50 Device to Cloud Authentication It makes no difference to the IoT device nor to the FIDO Authenticator whether it authenticates to another device or to a cloud service Challenge Cloud Service Authenticator FIDO Authentication (Signed) Response Public key 51

51 Device to Cloud Authentication It makes no difference to the IoT device nor to the FIDO Authenticator whether it authenticates to another device or to a cloud service Challenge Cloud Service Authenticator FIDO Authentication and the Authenticator can be embedded in smart fridges, smart thermostats and other IoT devices. (Signed) Response Public key 52

52 Conclusion 1. Authentication is the first experience of users with services and several device types. 2. Authentication needs to be convenient for the user and strong enough for the purpose. 3. We can do better than passwords + OTP. Look at the FIDO specifications for strong & convenient authentication, see 4. FIDO supports silent Authenticators. These Authenticators can be implemented in IoT devices. 5. FIDO authentication responses can be verified in small devices, allowing FIDO authentication to those IoT device. 6. FIDO can be combined with PoP Keys (RFC7800) in order to support authentication to cloud connected IoT devices 53

53 FIDO Authenticator Concept Optional Components Injected at manufacturing, doesn t change FIDO Authenticator User Verification / Presence Transaction Confirmation Display Attestation Key Authentication Key(s) Generated at runtime (on Registration) 54

54 Silent Authenticators 1. Definition, see FIDO Glossary 2. User Verification Method, see FIDO Registry 3. Metadata Statement, see FIDO Metadata Statements 55

55 FIDO Registration Authenticator select Authenticator according to copts; determine rpid, get tlsdata; clientdata := {challenge, origin, rpid, halg, tlsdata} copts: crypto params, credential black list, extensions Platform accountinfo, challenge, [copts] ai Relying Party (example.com) verify user generate: key k pub key k priv credential c rpid, ai, hash(clientdata), cryptop, [exts] cdh c,k pub,clientdata,ac,cdh,rpid,cntr,aaguid[,exts], signature(tbs) ac: attestation certificate chain s tbs c,k pub,clientdata,ac,tbs, s store: key k pub c 56

56 FIDO Authentication Authenticator Platform Relying Party select Authenticator according to policy; check rpid, get tlsdata (i.e. channel id, etc.); lookup key handle h; clientdata := {challenge, rpid, tlsdata} challenge, [aopts] verify user find key k priv cntr++; process exts rpid, [c,] hash(clientdata) cdh clientdata,cntr,[exts],signature(cdh,cntr,exts) s clientdata, cntr, exts, s lookup k pub from DB check: exts + signature using key k pub 57