The Future of Authentication for IoT

All Rights Reserved | FIDO Alliance | Copyright 20171
THE FUTURE OF
AUTHENTICATION FOR THE
INTERNET OF THINGS
FIDO ALLIANCE WEBINAR
MARCH 28, 2017

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

THE FACTS ON FIDO
The FIDO Alliance is an open,
global industry association of
250+ organizations with a
focused mission:
300+
FIDO Certified solutions
3 BILLION+
Available to protect
user accounts worldwide
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

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

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

WHY FIDO?
OTPs improve security but
aren’t easy enough to use -
and are still phishable
SMS RELIABILITY
TOKEN NECKLACE USER CONFUSION
STILL PHISHABLE
SECURITY
USABILITY
Poor Easy
WeakStrong
OTPs
SecurityUsability

THE WORLD HAS A “SHARED SECRETS” PROBLEM

WE NEED A
NEW MODEL

HOW ARE WE DOING IT?
ECOSYSTEM
STANDARDS
DEPLOYMENTS
USER EXPERIENCE

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

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

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

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

USABILITY
SECURITY
Poor Easy
WeakStrong
FIDO — A NEW PARADIGM:
=authentication
STRONGER
& SIMPLER

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

BUT WAIT…

THE WORLD HAS AN IOT SECURITY PROBLEM

WE NEED A NEW
AUTHENTICATION MODEL FOR
CONNECTED USERS & DEVICES

THANK YOU
ANDREW SHIKIAR
SR. DIRECTOR OF MARKETING
ANDREW@FIDOALLIANCE.ORG

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.

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

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

Scope
Cloud
Services

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

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.

Scope
Focus of this talk
User to standalone devices

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

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

IoT
Device
IoT
Device
Background
Perimeter
Internet
Infected Device
Attacks
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device
IoT
Device

Background

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

User to Device Authentication

User to Device interaction
Device
Without
keyboard
and display
?

User to Device interaction
IoT Device
Without
keyboard
and display
User needs some
computing device with
user input interface and
display
1
Security: Device could be infected, so
users don’t want to reveal bearer
tokens (like passwords, etc.) to it
2
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?
Convenience: Devices want to support
arbitrary user verification methods,
e.g. PINs, Fingerprint, Face, … - with
limited computing power

… did we see that before?
Device
TLS / DTLS or
other secure channel
See https://fidoalliance.org/events/fido-alliance-seminar-hongkong/
36

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

FirstAuthenticator Registration (Example)
IoT Device
Device in
factory default
settings state
1
2
Press
“register
button”
3
Start registration
process (for first
authenticator)

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

Devices with Cloud Dependency
Cloud
Services
User to cloud-connected devices
Rental Cars
Door locks
…
Parcel Lockers
Thermostats
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

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

FIDO Stack
Mobile
App
SDK
Cloud Service
Device
anchor
(see RFC7800)
JOSE Payload:
JWS signature, computed by Cloud Service
{“kid”:“1e8gfc4”,“alg”:“ES256”}
JOSE Header:
{
"iss": "https://server.example.com",
"aud": "https://client.example.org",
"exp": 1361398824,
"cnf":{
"jwk":{
"kty": "EC",
"use": "sig",
"crv": "P-256",
"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
"y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
}
}
}
42

FIDO Stack
Mobile
App
SDK
Cloud Service
Device
anchor
(see RFC7800)
4. FIDO Authentication to device
with signed JWT w/ PoP (FIDO)
Public Key as additional data

Gallagher Unlocks the Internet of Things with Nok Nok
44

Source: Philafrenzy, Wikipedia45

Source: Klaus Mueller, wikipedia46

Device to Device & Device to Cloud
Authentication

Scope
Device to device
authentication
User to device authentication
48

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

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

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

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

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 www.fidoalliance.org.
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

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

SilentAuthenticators
1. Definition, see FIDO Glossary
2. User Verification Method, see FIDO Registry
3. Metadata Statement, see FIDO Metadata Statements

Relying Party
(example.com)
accountInfo, challenge, [cOpts]
rpId, ai, hash(clientData), cryptoP, [exts]
verify user
generate:
key kpub
key kpriv
credential c
c,kpub,clientData,ac,cdh,rpId,cntr,AAGUID[,exts],
signature(tbs)
c,kpub,clientData,ac,tbs, s
store:
key kpub
c
s
PlatformAuthenticator
select Authenticator according to cOpts;
determine rpId, get tlsData;
clientData := {challenge, origin, rpId, hAlg, tlsData}
cOpts: crypto params, credential black list,
extensions
cdh
FIDO Registration
ai
tbs
ac: attestation certificate chain

Authenticator Platform Relying Party
rpId, [c,] hash(clientData)
select Authenticator according to policy;
check rpId, get tlsData (i.e. channel id, etc.);
lookup key handle h;
clientData := {challenge, rpId, tlsData}
clientData,cntr,[exts],signature(cdh,cntr,exts)
clientData, cntr, exts, s
lookup kpub
from DB
check:
exts +
signature
using
key kpub
s
cdh
challenge, [aOpts]
FIDOAuthentication
verify user
find
key kpriv
cntr++;
process exts

The Future of Authentication for IoT

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to The Future of Authentication for IoT (20)

More from FIDO Alliance (20)

Recently uploaded (20)

The Future of Authentication for IoT