ankur taly, google inc. an identity and authorization...
TRANSCRIPT
An Identity and Authorization Model for Internet of Things (IOT)
Ankur Taly, Google Inc.
Joint work with Asim Shankar, Gautham Thambidorai, Suharsh Sivakumar, Ryan Brown, Martin Abadi, Mike
Burrows, Adam Sadovsky and Himabindu Pucha
Presentation at VCEW 2015
The Internet of Things (IOT)
Physical devices made accessible over the network.
Exciting new possibilities!!
img source: http://www.ti.com/lsds/media/images/wireless_connectivity/50BillionThings.png
and some not-so-exciting ones as well!!
Internet of Things (IOT) Security
IOT Security Vulnerabilities
Top IOT Vulnerabilities● Insufficient Authentication
and Authorization● Lack of Transport Encryption● Insecure Web Interfaces● Insecure Software Updates● Insecure Defaults
Security First: Bake in security mechanisms from the ground up.
IOT Security PrinciplesIdentity and Access Control
● Every “actor” (user, device, app, process) must have unique identity.● All network communication must be encrypted and mutually authenticated.● All access to device capabilities must be authorized and auditable.
Device Protection
● Devices must run verified-boot OS, with automatic and secure updates.● Applications running on devices must be appropriately sandboxed.● Devices must be protected from intrusion and remote code execution attacks.
[This Talk]
Plan
● Identity and Access Control Model
○ Principals and Blessings
○ Authentication and Authorization
● Case Study: Smart Door Lock
● Practicalities
● Conclusion
Cloud-based ApproachPros:● Centralized access management● Seamlessly jump across networks● Easy delegation and sharing
ConnectivityAuthenticationAuthorization
This Work: A peer-to-peer, decentralized approach to identity, authentication and authorization.
Cons:● Cloud service becomes an attractive
target for compromise● Different manufacturers may trust
different cloud providers● Loss of functionality when offline● Inefficient
can’t talk
Our Design Goals
● Fine-grained Identities○ Can distinguish between Alice’s son Bob’s tablet’s Farmville app and
Alice’s daughter Carol’s phone’s Amazon app.
● Peer-to-peer Authentication, Authorization and Delegation○ Alice’s tablet can interact and share access with Bob’s phone by
communicating directly with it.○ The cloud can be leveraged when available but it shouldn’t be
necessary.
● Human-friendly Authorization policies
Identity ModelPrincipals and Blessings
Principal● An entity that can communicate externally.
○ Devices, Apps on devices, Services.
● Has a unique public/private key pair (P, S).○ Private key is never shared over the network.
Blessings● Each principal has a set of hierarchical human-readable strings
bound to it, called blessings.Example: Alice’s television (principal: Ptv, Stv) may have blessings:○ google/alice/tv ○ samsung/products/tv/123
● Principals are authenticated and authorized based their blessings. Example: Alice’s devices authorize all principals with blessing names matching google/alice/*.
Simple Distributed Security Infrastructure (SDSI), Lampson and Rivest, 1996
Blessings● Blessings are certificate chains bound to the principal’s public key.● Each certificate has a Name, PublicKey, Caveats and Signature.
PGoogle
Till 6/30/2016
Signed by SGoogle
alice
PAlice
Till 7/4/2015
Signed by SGoogle
Very Simple certificate format!
self-signed
(PAlice, SAlice)
Blessing Root● Blessings are rooted in self-signed certificates.● But then anyone can write a self-signed certificate with name
Google!!Blessing root <P
google, google> google
PGoogle
Till 6/30/2016
Signed by SGoogle
alice
PAlice
Till 7/4/2015
Signed by SGoogle
Blessing is valid only if its root name and public key are recognized
Blessing Root RecognitionEach principal recognizes certain blessing roots (public keys) as authoritative for certain blessing names.● PGoogle is recognized for blessing beginning with google/, but not facebook/
● Any principal can become a blessing root
● Different principals may recognize different roots.
Blessing Root Blessing Pattern
PGoogle google/
PFacebook facebook/
PTwitter twitter/
Identity Providers: “Well-known” set of blessing roots
Extend one of your Blessings and bind it to another principal.
The Bless Operation
Bless
houseguest
PBob
(PAlice, SAlice)
Dynamic Identity Creation OR Bound Capability Grant!
(PBob, SBob)
PGoogle
Till 6/30/2016
Signed by SGoogle
alice
PAlice
Till 7/4/2015
Signed by SGoogle
houseguest
PBob
Till 7/4/2015: 6PM
Signed by SAlice
PGoogle
Till 6/30/2016
Signed by SGoogle
alice
PAlice
Till 7/4/2015
Signed by SGoogle
Till 7/4/2015: 6PM
Signed by SAlice
But Alice wants Bob to only have access to her TV, not her door lock or thermostat!
Caveats
houseguest
PBob
Till 7/4/2015: 6PM
Signed by SAlice
houseguest
PBob
Till 7/4/2015: 6PM
Only to access alice/hometv
Signed by SAlice
Specify arbitrary restrictions here
Bob has the name google/alice/houseguest● as long as the time is before 7/4/2015: 6PM● as long as the device being accessed is alice/hometv
Macaroons: Cookies with Caveats for Decentralized Authorization, Politz et al., NDSS’14
PGoogle
Till 6/30/2016
Signed by SGoogle
alice
PAlice
Till 7/4/2015
Signed by SGoogle
Caveats are powerful● Services can define their own caveats.
Bless the Valet such that:○ valet is only authorized to drive for < 5 miles○ only for the next 3 hours○ cannot access trunk or infotainment system○ but can access GPS
● These caveats are called first-party caveats.● They are validated by the target service (first-party) when the
blessing is used to make a request.
Third-party Caveats
● Caveats that are validated by a specific third-party.● Target service (first-party) only expects a “discharge” (proof)
that the caveat has been validated by the specific third-party.
ID: <hash of Restriction and Loc>
Restriction: within 10m proximity
Loc: alice/proximity
Verification Key: PProximity
Third-party Caveat
ID: <same as caveat.ID>
Caveat: for next 1 minute
Signed by SProximity
Third-party Discharge
Mechanics
proximity caveat
proximitydischarge
(PProximity, SProximity)
(PBob, SBob) (PTV, STV)
Perform proximity checks
12
3
Alice’s proximity discharger
google………
alice………
houseguest……...
proximity caveat
proximitydischarge+
google………
alice………
houseguest……...
proximity caveat
Third-party Caveat Examples● Revocation caveat
○ Third-party caveats provide a natural refresh mechanism.○ Subsumes Online Certificate Status Protocol (OCSP).
● Social network caveats ○ G+ must assert membership in “work” circle.
● Parental controls caveats○ Kids can watch TV only if Mom approves.
Validating Blessings
alice
PAlice
Till 6/30/2016
Signed by SGoogle
houseguest
PBob
Till 7/4/2015
TPCaveat: PProximity
Signed by SAlice
How does the TV validate Bob’s blessings?
TPDischarge+
PGoogle
Till 6/30/2016
Signed by SGoogle
Three Steps:1. Verify Certificate Signatures.
Bob can be recognized as google/alice/houseguest.
2. Validate all first-party and third-party caveats.3. Verify that the blessing root is recognized.
Authentication and Authorization
All communication must be encrypted, mutually authenticated and authorized.
Authentication and AuthorizationClient: Initiator of request Server: Responder of request
Mutual Authentication● Each end learns the other end’s blessings and is convinced that the
other end possesses the corresponding private key.
Mutual Authorization● Each end validates the other end’s blessings and evaluates the
blessing names against an authorization policy.
Mutual Authentication Protocol
gx
gy
SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman, Krawczyk et al., CRYPTO’03
Client Server
Bob learns BlessingsTVand authorizes them
TV learns BlessingsBob and authorizes them
Derive (authenticated-encryption) key k from DH secret
{ BlessingsTV, SignTV(<"s",gx, gy>) }k
{ BlessingsBob, SignBob(<"c", gx, gy>) }k
Diffie-Hellman (DH) Exchange
Server presents its blessings before the client
Private Mutual Authentication
● Neither the server nor the client wants to present its blessings first.
I only reveal my name to delegates of google/alice
I will only reveal my name to google/alice/tv
● How do we resolve this deadlock?
Relevant cryptography research (carried out in the context of spies)● Oblivious Signature-Based Envelope - Li et al., PODC‘03● Secret Handshakes from Pairing-Based Key Agreements - Balfanz et al., S&P‘03
Authorization
Validate Blessings
ReferenceMonitor
ProcessRequest
+google/alice/houseguest PASS
FAIL
Authorization policies are based on blessing names.
1) Verify certificate signatures2) Validate caveats3) Verify blessing roots
Verify that blessing name satisfies the authorization policy(e.g., ACL)
Access Control Lists (ACL)Set of authorized blessings specified using explicit ACLs.
Alice’s TV Label Blessing Patterns
Admin In: google/alice
Photos In: google/alice/*
Movies In: google/alice/devices/*
Bob with blessing google/alice/houseguest can browse photos but cannot watch movies
, google/carol/devices/phone
Authorize by editing the ACL or Authorize via blessing?
Distributed GroupsSet of authorized blessings specified using distributed groups.
ReferenceMonitorLabel Blessing Patterns
Admin In: alice
Photos In: g<Carol Devices>
Movies In: alice/devices/*
GroupCarol Work
Devices
google/carol/devices/phonegoogle/carol/devices/tabletg<Carol Work Devices>
GroupCarol
Devices
/TVApp
g<Carol Devices>/TVApp matches● google/carol/devices/phone/TVApp
● google/carol/devices/tablet/TVApp
● ...
Distributed GroupsVery expressive ACL model, but:● How can group servers answer queries while keeping their
membership lists private?● What happens when group servers are unreachable?● What if there are cycles?
Model group definitions as a (distributed) grammar and perform top-down parsing.
Distributed Authorization with Distributed Grammars, Abadi et al. (In Submission)
SummaryPrincipal and BlessingsA principal is a unique public/private key pair with blessings (human-readable names) bound to it.
Blessing names based Authentication and AuthorizationPrincipal are authenticated and authorized based on their blessing names.
Fine-grained DelegationA principal can bind an extension of its blessing to another principal under caveats.
Case Study: Smart Lock
Why use smart door locks?
● Remote locking/unlocking.● Keyless proximity-based access.● Maintain an audit log of who got in.● Mint new (virtual) keys and share with others. ● Some also have a camera that will take the visitors picture.
Blessings-Based Lock
I am lockcorp/1234
Claim (“alice-door”)
Bless back as: alice-door/key
Lock using alice-door/key
Unlock using alice-door/key
Blessing Store
google/alice
alice-door/key
Authorization Policy
Claim: Allow Everyone
Blessing Store
alice-door/key/friend
Unlock using alice-door/key/friend
Now I am alice-door
Authorization Policy
Lock: Only extensions of alice-door/key
Unlock: Only extensions of alice-door/key
BLESS
Blessing Store
lockcorp/1234
alice-door
Create self-signed blessing with name alice-door
Blessings-Based Lock
● Fully Decentralized○ No cloud server controls access to all locks from a particular
manufacturer.○ Each lock device is its own identity provider.
● Works Offline○ No internet access required to interact with the lock.
● Fine-grained Auditing○ Each lock device can keep track of who accessed it and with
what blessings.
Practicalities
Blessings Management● Devices and applications would accumulate multiple
blessings over time. So Bob’s phone would have:○ google/bob/devices/phone
○ motorola/model-xxx
○ google/alice/houseguest
● Which blessings should be presented to whom?● How should the User Interface (UI) be designed?● Need to be careful to avoid confused deputy attacks.
Blessing or changing ACLs?Authorize by Blessing when:● Delegation when you do not control the ACL.● Authorization is very constrained.● Example: share “key” to a smart lock.
Authorize by changing ACLs when:● Authorization is broad.● Authorization is provided to a group at once.● Example: share a document with all VCEW 2015 attendees.
Private Key ManagementKey challenge in making this model work● How we protect a device’s private keys from getting compromised?● Many different hardware architectures and operating systems.● Devices may have multiples private keys (one for each app).
An Approach: Use a security agent (e.g., Plan9’s factotum)● Special process that manages private keys and performs all
cryptographic operations.● May store private keys in a TPM, if available.● May adjust itself based on the hardware.
Key Rotation
● Good News:○ Authorization is based on names and not public keys so services
are not affected.○ Can you third-party caveats for revoking old keys.
● Work in progress:○ Mechanism for refreshing existing blessings on the old key.○ Mechanism for refreshing blessing grants made using the old key.○ Mechanism for rotating Identity Provider keys.
ConclusionsThe Internet of Things holds great promise for an exciting new world if only we can build it securely.
Our Work: Blessings-based Identity and Access Model for Internet of Things.● A unified and decentralized identity model for all “things” ● All communication is encrypted, mutually authenticated and authorized● Peer-to-peer, fine-grained delegations● Simple authorization policies based on names
Thank you for your attention!Ankur Taly ([email protected])
Ongoing WorkIdentity and Access Control
● Key rotation mechanism● Private mutual authentication using “secret handshakes”● TPM-backed verified boot for devices => Device Blessings
Device Protection
● Signed application binaries and serverless app-stores.● Sandboxing all applications running on devices [POLA]● Protecting devices from intrusion and remote code execution attacks
Backup Slides
Identity ProviderAny principal can become a blessing root, but thenAlice’s phone has to recognize the blessing roots of all devices it interacts with :-(
Solution: Have certain widely-recognized roots in the systeme.g., Google, Facebook, Samsung, …● Users would authenticate to them and obtain a blessing● e.g., Alice would obtain google/[email protected], and then
delegate it ○ google/[email protected]/tv,○ google/[email protected]/tv/netflix
IOT Security Challenges
● Several Dozen devices per user● Multitude of form factors, hardware characteristics, sensors,
I/O capabilities etc.●● Software updates are hard to carry out.● Security is not a priority.Privacy and Transparency
● Devices must only collect data that is needed for their functionality● All data exfiltrated from devices must be auditable
IOT Security Landscape● Controlling who can access what capabilities on a device● Protecting all network communication● Protecting devices from malicious software● Protecting devices from intrusion and remote code execution● Patching software bugs on devices● Controlling what private data is collected by devices● Auditing what data is exfiltrated by devices
Security First: Build security mechanisms from the ground up
User-Interface (UI) DesignWhen Alice blesses Bob’s phone
● How does she discover Bob’s phone?● How does she select which of her blessings she want to
extend to Bob?● What is the UI for selecting caveats to add to the blessing?
NotIn: alice/devices/phone
Policy 1: Delegates and Blessers onlyOnly allow your own blesser or delegates
Alice’s smart door lock with blessing alice/doorlock Allows➢ alice➢ alice/doorlock➢ alice/doorlock/key➢ alice/doorlock/key/spouse
Rejects➢ bob➢ alice/houseguest
Identity and Access Control
● Identity○ How do I identify the TV in my house?○ Device owner? Device manufacturer? App author? All of these?
● Authentication, Authorization, and Audit○ How does my phone authenticate to my TV, and vice versa?○ How do I set authorization policies for who can access my TV?○ How do I monitor the set of devices that connected to my TV
over the last week?
Blessing Root
PMallory
Till 6/30/2016
Signed by SMallory
houseguest
PBob
Till 7/4/2015
Signed by SAlice
Blessings are rooted in self-signed certificatesAnyone can call their public key google.
Blessing root <P
Alice, alice>
is not recognized
Blessing Roots● Blessings are rooted in self-signed certificates.● Mallory can forge the alice/houseguest blessing!
alice
PMallory
Always Valid!!
Signed by SMallory
(PMallory, SMallory)
houseguest
PMallory
Always Valid!!
Signed by SMallory
Blessing root <P
Mallory, alice>
is not recognized
Identity Provider● The root certificate is “self-named”
● Each principal recognizes specific root public keys for specific parts of the blessings space. PGoogle is recognized for blessings beginning with google/ and not facebook/
● Identity providers: “Well-known” set of roots certificate signers.