3. IDENTITY 101
3
IDENTIFICATION
WHO ARE YOU?
AUTHENTICATION
CAN YOU PROVE IT?
WHAT DEGREE OF
ASSURANCE?
AUTHORIZATION
OK, I BELIEVE YOU. I GET TO
DECIDE WHAT YOU GET TO
DO OR NOT.
8. Credentials
Users
Mobile.
Cloud.
The Perimeter has Dissolved.
Sharing of Information
& Resources.
The Good ol’ Days. Users, their credentials,
and the information they accessed were
all within the secure perimeter of the
Enterprise.
12. REAL-LIFE IDENTITY
12
BOB
IDENTIFY: “HI, I’M BOB”
AUTHENTICATE: “PROVE IT”
1. DMV
“I HAVE AUTHENTICATED YOU
HERE IS A TOKEN ASSERTING MY
AUTHENTICATION OF YOU AS WELL
AS SOME ATTRIBUTES OF YOU”
2.
16. Identity 2.0
IDENTITY: “I AM OFFICER BOB”
AUTHENTICATE: “PROVE IT”
CREDENTIAL
REPOSITORY
Agency
IdM FUNCTION
1.
BIOMETRIC
***********
PASSWORD SMART CARD
I HAVE AUTHENTICATED YOU, BOB. HERE IS A
TOKEN ASSERTING MY AUTHENTICATION OF
YOU …AS WELL AS SOME ATTRIBUTES OF YOU.
2.
Name: Officer Bob
Agency: Schaumburg Police Department
Role: Sergeant
Languages: English, Spanish, Russian
Qualifications: Firearms, CPR
Contact-mobile: 847-555-1234
Contact-email: bob@schaumburgPD.gov
User Authentication: RSA 2-factor
Signed by: Village of Schaumburg IdM
17. Identity 2.0
17
Separation of Identity Provider and Service Provider functionality
Identity 2.0 is the separation
of the Identity Provider from
the Service Provider
19. Centralized Credential
Management
19
IDENTITY PROVIDER APPLICATION 1
Service Provider Application
logic
Focuses strictly on the service
the app is looking to provide
Leverages identity &
credentials provisioned in
Identity Provider
APPLICATION 2
Service Provider Application
logic
Focuses strictly on the service
the app is looking to provide
Leverages identity &
credentials provisioned in
Identity Provider
Identity = Alice
Password = abc123
Attribute-1 (e.g. email)
Attribute-2 (e.g. phone number)
Attribute-3 (e.g. dept. no)
Password change management =
90 days
Password complexity rules
Password reuse rules
Activate account
Suspend account
Delete account
INTEGRATES WITH AGENCY’S EXISTING IDENTITY MANAGEMENT
SYSTEM (E.G. ACTIVE DIRECTORY)
25. • Strong Authentication
Strong Authentication
25
76%of 2012 network intrusions
exploitedweak or stolen credentials
In 2007, ~30 vendors in
authentication. Approx
imately 12 new vendors
have been added per
year. Today there are
over 100 vendors.
26. Source: PingIdentity
AT WORK AT HOME
Memorization
One Constant:
CHANGE
Re-Use
Avoid Change
The average corporate user
maintains 15 passwords within
both private and corporate
spheres
27. • Like the cockroach…
…passwords will outlive us all
• But that does not mean ….
…. we shouldn’t try to exterminate them
28. STRONG AUTHENTICATION
28
SOMETHING I AMSOMETHING I HAVESOMETHING I KNOW
CJIS REQUIRES STRONG AUTHENTICATION –
MSI HAS SOLUTIONS TO MEET THOSE NEEDS TODAY
29. • The Identity problem
– Who are you
– Prove it
– how confident are we in the “proofing”
• Federal Standards defined “how certain”
– Level Of Assurance (LoA)
– Defined in M-04-04 (Dec 16, 2003)
• EXECUTIVE OFFICE OF THE PRESIDENT, OFFICE OF MANAGEMENT AND BUDGET
OMB LoA Description
Level 1 Little or no confidence in the asserted identity’s validity.
Level 2 Some confidence in the asserted identity’s validity.
Level 3 High confidence in the asserted identity’s validity.
Level 4 Very high confidence in the asserted identity’s validity.
35. PILLARS OF IDENTITY 2.0
35
WHAT DO YOU GET?
MOBILE
FRIENDLY
CLOUD
READY
INDUSTRY
DOMINANT
OPEN
STANDARDS
CENTRALIZED
CREDENTIAL
MANAGEMENT
SINGLE
SIGN
ON
FEDERATION:
PORTABLE &
INTEROPERABLE
STRONG
AUTHENTICATION
36. 36
In a deperimiterized mobile & cloud
world, where first responders are
accessing information – located
anywhere – from anywhere – Identity
*IS* the new perimeter
38. July 17, 1996: Emergency services personnel from Suffolk County, NY and the United States Coast
Guard respond to a report of a catastrophic explosion and the crash of a passenger airliner over
the ocean off the southern coast of Long Island. The initial assumption is a nexus to terrorism.
The East Moriches Coast Guard Station is designated as the operations command post, staging
area, and evidence collection point. As the incident shifts from response to recovery, personnel
from various response disciplines and levels of government stream into the station. Among them
is Lieutenant Colonel David Williams of the U.S. Army Reserve. LTC Williams, dressed in his U.S.
Army Reserve flight suit, presents identification, enters the site, and assists in the operation by
landing helicopters on the designated helipads. On the third day of his work, LTC Williams is
questioned concerning his identity and affiliation. Following a brief investigation, LTC Williams is
identified as an impostor, escorted from the property, and charged by the Suffolk County Police.
September 11, 2001: When the Pentagon was struck it resulted in a massive response of public safety
personnel from fire, EMS, and police. Given the technology used at the time, it was impossible to
authenticate and validate emergency responders at a pace necessitated by the disaster. While the
majority of emergency responders already had identification cards, their credentials were not
recognized at all levels of government or by the various jurisdictions. The incident commanders
on site either had to assume that people were who they said they were, or they had to deny or
delay access of critical emergency personnel to the crash scene. This same scenario could be
applied to any disaster at any secured building in any city or state.
39. • Single Factor: Choose ONE OF
SOMETHING I
AM
SOMETHING I
HAVE
SOMETHING I
KNOW
• Multi Factor: Choose TWO OR MORE
SOMETHING I
AM
SOMETHING I
HAVE
SOMETHING I
KNOW
40. • User Authentication - Factors
Something I Know Something I Have Something I Am
Pin Smart badge Brainwave (EEG)
Password/Phrase OTP Token Heart Rhythm (ECG)
Gesture Key Fob (Yubico) Voice
Shape Smartphone/Tablet Fingerprint
Pattern Bio-stamp/Tattoo Finger/hand vein
Wearable Iris scan
Facial scan
NFC Ring
PIVOTP
41. • 1. REMOTE ACCESS
• CJIS MANDATES STRONG AUTHENTICATION
• 2. PHYSICAL ACCESS
• FRAC CARDS FOR INTEROPERABILITY
• 3. DEVICE ACCESS
• SENSITIVE DATA ON DEVICES & OPEN SESSIONS
Authentication for Public Safety
42. • Think To Authenticate
– Started as “brain fitness”
– Your brainwave is unique
– Focus on a thought
– Some Difficulties
• Slow
• Focus
• Very early research
NeuroSky
43. • Key Stroke to authenticate
– Something I know (simplified Password)
– Something I am
• Dwell time
• Flight time
– Stops password sharing
44. • EKG to authenticate
– Your EKG is unique
– Not affected by caffeine or exercise
• Heart rate, yes
• EKG characteristics, no.
– How many sensors?
• Hospital = 12
• Authentication = 2
– Communicates to your device
• Bluetooth
• NFC
Bionym
45. • Smartbadge Tap to authenticate
– Uses NFC Technology
• Standard supported by most smartphones
– Federal PIV card standards
• Personal Identity Verification card
• FIPS PUB 201-2
– PIV-I/FRAC cards
• First Responder Authentication Credential
• Future capability
– Smartbadge turns your phone into a badge
– Draft NIST SP 800-157
Card emulation
on radio
Tap Smart Card
LOGON
47. Feature extraction &
Template creation Database
BE BE’
Database
Matching Function
ID
BA BA’User
BE’
ID
User
Enrollment
Authentication
Feature extraction &
Template creation
Decision (Y/N)
Database
Matching Function
BI BI’User
Identification
Feature extraction
Identity
Sensor
Sensor
Sensor
52. • Assets require “user” access controls?
– Records management
– CAD
– CJIS
– Location
– Messaging
– Logging
– PTT services (?)
– …
• Single Factor or Multifactor
• Device or User Authentictaion
53. • Most of this is standards
– Standards
• NIST
• FIDO
• Global Platform
• Technology Enablers
• Secure elements (CRYPTR micro)
• TEE
• Wireless tokens/secure elements
• Wearable Biometrics
Notas del editor
SPEAKER NOTES:
Identification, authentication, and authorization represent the three cornerstones of digital identity.
Identification is the process of telling some entity who you are. This is analogous to making a phone call and the person at the other end of the line asking you for your name. In low assurance environments this is sufficient, but in most cases it is not. In most cases the person you are identifying yourself to will want some level of assurance that it is really you. This is called authentication. Authentication is the process of claiming that you really have the right to claim the identity that you are providing the other party. In phone calls, weak forms of authentication are typically used, such as a request for a mother’s maiden name or the last for digits of a social security number. In digital identity to on-line services, the most common method of providing assurance of a claimed identity is a password. If you can provide that password that is associated with the identity you claim (e.g. a username) then you have “authenticated” to the on-line service. Authentication simply means however that the personal or entity that you are presenting your identity to can believe (with some level of assurance) that you really have the right to claim that identity. It does not however, necessarily entitle you to any privileges. Just like a driver’s license can be used to prove your identity to a police officer during a traffic stop, proving your identity does not entitle you to use the officer’s radio. In digital identity, authentication to an on-line server my assure the server that you are who you claim to be, but that does not mean that you get access to all information on that server. Authorization takes places once authentication completes, and what you are authorized to do often is based upon attributes (such as rolls and certifications) associated with your identity.
In the past (what we refer to as Identity 1.0) – and still too much today – Identity is solved in silos. Each application not only acts as a service provider, but also provides the user with an Identity, hence acting as an identity provider.
This causes a multitude of headaches for the end user, for the admin, and even for the application developer.
User Headaches:
must remember multiple usernames, passwords
must enter those in each time accessing any application
need to change passwords at different intervals, in different locations
if app not accessed frequently, might forget password, need to call help desk to reset password
might also get locked out of app if not used within a certain interval
Users pick weak passwords, reuse passwords, or write them down
Admin Headaches:
high volume help desk calls due to forgotten passwords or locked out accounts
no single way to onboard / offboard user
must manage user credentials in multiple locations
difficult to enforce common password management policy
Developer Headaches:
Many apps not built by security engineers, make poor authentication choices
Detracts cycle time from actual core feature set
Traditionally, users worked within the confines of a secure perimeter, had their identity provisioned within that secure perimeter, and access applications and resources within the security perimeter.
Over the past few years, this has been disrupted. Broadband coverage has extended once wired application into the mobile environment, supported by mobile computing platforms such as Android and iOS. The worker has moved outside the perimeter. But at least for a while, they were still accessing content within the secure perimeter. But then cloud happened. The applications that the user relies upon are no longer within the perimeter, but reside within the cloud.
So users are accessing data that cloud be stored anywhere, one their mobile device so they could be located anywhere. Where is the perimeter? It has dissolved.
Perimeter-based security controls or no longer sufficient alone. When the users are working outside of the perimeter and accessing information that resides outside of the perimeter, the only criteria that applications can base access and control decisions on is their assurance of the identity of the user requesting access to resources or data applications. Identity has become the new perimeter.
Traditionally, users worked within the confines of a secure perimeter, had their identity provisioned within that secure perimeter, and access applications and resources within the security perimeter.
Over the past few years, this has been disrupted. Broadband coverage has extended once wired application into the mobile environment, supported by mobile computing platforms such as Android and iOS. The worker has moved outside the perimeter. But at least for a while, they were still accessing content within the secure perimeter. But then cloud happened. The applications that the user relies upon are no longer within the perimeter, but reside within the cloud.
So users are accessing data that cloud be stored anywhere, one their mobile device so they could be located anywhere. Where is the perimeter? It has dissolved.
Perimeter-based security controls or no longer sufficient alone. When the users are working outside of the perimeter and accessing information that resides outside of the perimeter, the only criteria that applications can base access and control decisions on is their assurance of the identity of the user requesting access to resources or data applications. Identity has become the new perimeter.
Traditionally, first responders have accessed a set of application provided strictly by their home agency.
Today and increasingly going forward, first responders will require access to application and services provided outside of their home agency. For example, the first responder might need to access an interoperable PTT group offered by FirstNet, might need access to a records database provided by another agency, might need access to a regionally hosted service, or might access one or more services that are hosted in the cloud.
Note: Tighter budgets are pushing more an more apps into the cloud (we have seen this trend ourselves within MSI as most of the apps we use are now cloud-hosted).
WE NEED AN IDENTITY ECOSYSTEM…
BUT FIRST, IT IS WORTH WHILE TO SEE HOW REAL LIFE IDENTITY WORKS
In the real world, we prove our identity to state drivers license facility. We identify ourselves to the DMV and they ask us for some set of credential to assure them that we have right to claim the identity .
Once the DMV has authenticated us, they issue us a token which contains assertions about us. The token is our driver’s license. Assertions are claims that the DMV is making about us, since it has already authenticated us. Examples of assertion claims include our birthday, our address, our legal name, and the type of vehicle that we are licensed to drive (e.g. car vs. motorcycle vs. large truck).
The token also has an expiration data attached to it, after which it should no longer be considered trustworthy. And it is sealed by the DMV, so anybody who see’s this can immediately identify which state the license was issued to (e.g. Illinois, Texas, California, etc.)
With a this token now in our possession, we can use this token to authenticate to various other entities.
For example,
It can be used to prove our identity when we look to rent a car from a car rental agency.
It can be used to prove our identity to federal security officers when traversing a security checkpoint in the airport,
It can be used to prove our identity to a public safety officer when pulled over for a traffic stop
The rental car agency, the airport security officers, and the police officer are able to consume this token and believe that it is you, because they INHERENTLY TRUST the state DMV which has authenticated you and issued you this token.
The rental car agency, the airport security officers, and the police officer are also able to use the assertions within your driver’s license (token) to make authorization decisions. For example, presenting your license to the rental car agency gives them full assurance of your identity, but they might look at your date of birth assertion and determine that because you are only 23, you don’t meet their policy of needing to be 25 to rent a car. At the airport security gate, they are once again assured of your identity, but they might tell you that you are not authorized to fly, because you are on a federal do-not-fly list. And finally the public safety officer – also assured of your identity – might notice that your license has been expired, and hence you are no longer authorized to drive.
An important aspect of real life identity is that it is portable across jurisdiction boundaries. For example, a drivers license issued in Illinois can be used to prove your identity to people Wisconsin, and licenses issued in Wisconsin can be used to prove our identities to people in Illinois. This is powerful because we do not need to obtain a new drivers license from every state that we drive through – imagine what a pain that would be!! This is possible because there exists a legal degree of trusts between states, that each state trusts the other state to properly vet their citizens when issuing them a license.
Each state DMV is able to validate your identity in its own way. This is important, because it enables states to move ahead with new technologies, without having to wait on each other state to catch up. For example if Illinois invests in next-generation biometric identification, they can use this new technology, without having to wait for other states to make the move.
Lastly, another important aspect of real life identity is that it can be used as a factor to trade up to higher level credentials. For example, a state driver’s license can be used as one factor in obtaining a national passports, which enable trust at an even higher level (e.g. it is has a trust level that spans the globe).
IdM = Identity Management
Here we can see a picture that looks almost identical to the real life DMV example. But in this case, the user is a first responder, and instead of authenticating to the DMV, they are authenticating to their agency’s IT system (much like we authenticate to Active Directory within MSI today).
Each agency can implement this as they see fit. Today most people still authenticate using a username and password, but some agencies might begin moving toward stronger authentication credentials such as biometrics or smart cards. Regardless, once the user authenticate to their home agency IT system, they are issued a token asserting their authentication, and possibly some additional attributes as well. Example of additional attributes that might be asserted within an first responder’s token include the name of their agency, roles within the agency (e.g. Sergeant, Detective), spoken languages, certifications (e.g. NCIC), etc. These additional assertions can then be used by applications and services that the first responder presents their token to in order to make authorization decisions.
Identity 2.0 mirrors real-life identity, and built upon the notion of a separation of the Identify Provider and the Application (e.g. Service Provider).
Like real life identity, a user goes to a single place to prove their identity. This place then issues the user a token containing assertions. This token can then be used to authenticate to any number of applications and services. The applications and services no longer need to know the user’s password, instead they can focus on the functionality that their application was designed to provide.
Centralized Credential Management enables the agency IT admin to provision to on-board and off-board the user in a single location, and for all applications within the agency to leverage that credential. On-boarding is the process of giving the user a logon account (e.g. username and password). Off-boarding is what happens when a user leaves (e.g. removing access). If every application maintained a username & password than the IT admin would need to go to potentially many different places to on-board or off-board a user. Centralized credential management gives them a single place to do this.
Another benefit that this provides is the ability to enforce password rules such as password strength and password changes (e.g. user must change their password every 30 days). This would be incredibly difficult to realize if every application maintained their own usernames and passwords and implemented their own password rules.
Centralized Credential Management also enables some set of common attributes that are shared across applications to be centrally managed. Such common attributes might include email address, department number, desk phone, mobile phone, etc. Applications may still continue to manage their own attributes that are unique to that application, but they are able to map those attributes to the common identity asserted by the centralized credential management server.
Centralized Credential Management eliminates many headaches of the IT admin and streamlines their workflow.
And just like real life identity, this token issued by the home agency containing assertions about the first responder can be used to gain access to applications and services within the responder’s home agency, and also to applications and services OUTSIDE OF THE HOME AGENCY.
This is possible since once applications are updated to consume tokens instead of passwords, these applications no longer need access to a responder’s password. The first responder only presents their password to their home agency authentication server, which gives the responder’s device a token. The token is presented to applications and services outside of the home agency, and because there is a mutual trust in place, and the token says “my agency authenticated me already” the regional or nationwide or outside agency apps are able to authenticate the first responder.
However, just like real life identity, just because outside apps & services trust the first responder is who they claim to be, authorization decisions are still made locally by the service provider. This is a very important distinction, because on thing that our customers are very concerned about is local control. So it is important that they understand that even though they trust the token issued by an outside agency, the agency providing the service still gets to decide what the responder can or cannot do. For example, they might say that “okay – I believe you are officer Bob from Chicago, but I’m only going to let you read this database, you cannot write to it.” Or maybe they only give read access to some set of data, not the full set.
In other words, we are doing centralized authentication, but distributed authorization, where authorization is always dictated by local agency policy control.
Authentication is the process of providing a third party – a person, an application or a service – with assurance that you have the right to claim the identity that you are presenting.
One form of providing such assurance over the phone is providing a mother’s maiden name or the last 4 digits of a social security number. While this is better than nothing, it does not provide a very high degree of assurance that the person is who they claim to be. Passwords are the most common credential type used for authenticating an identity. Passwords are better than asking for social security numbers which tend to be pretty public or easily obtained, but they are still relatively week. Users often pick easy passwords that are easy to guess, or they pick hard passwords and write them down where they can be copied. Users reuse passwords across many different applications, meaning a leak of the password for any one application could compromise every other application. Passwords can be cracked using dictionary attacks, they can be stolen through phishing attacks or man-in-the-middle attacks, or may be captured through malware running on the device such as a keystroke logger. Hence passwords must only be considered a very weak form of authentication. When a user attempts to access a high assurance resource of service (such as sensitive or classified data, criminal records, etc.) a higher degree of assurance is most often required.
Stats source is PING Identity: http://www.slideshare.net/PingIdentity/password-proliferationinfographicpingidentity-27941353
At Home: 30 passwords
At work: 17 Passwords
Benefits access (health care, payroll, corporate card)
Industry associations memberships
So we suffer from PASSWORD FATIGUE… I DO.
… or minimally… we need to simplify passwords (make them short) and longer lived (e.g. a PIN)…
How…by adding a second factor. But Ideally, lets eliminate them if possible.
Strong Authentication involves using 2 or more credential types to prove an identity. Credential types typically fall into one of three categories:
Something I know (e.g. the traditional password, Mother’s maiden name, etc.)
Something I have (e.g. RSA or Entrust card, SmartCard, Yubikey, etc.)
Something I am (e.g. biometric – fingerprint, iris scan, voice or facial recognition, etc.)
This is considered strong because now an attacker must steal multiple credentials in order to impersonate a user and gain access to data. For example if using “something I know” + “something I have” the attacker must steel information inside the user’s head (e.g. password) and must steal something the user has (e.g. a smartcard).
When we MSI employees logon to the VPN from home today, we use strong authentication. We each have an entrust token installed on our machine (or possible a physically separate card) and a 4-digit PIN that resides in our head. An attacker wishing to compromise a user’s VPN access would now need to steal their physical laptop (something I have) and steel their 4-digit PIN (something I know). This is of course not impossible, but it provides a much greater degree of assurance to the party looking to authenticate a user’s identity.
Access to CJIS data exposed by the FBI within the United States requires strong authentication for accessing the data when mobile (e.g. in a police car, or from a mobile device such as an LMR radio, Android smartphone, iPad, etc.). MSI has solutions to meet these needs today.
Identity 2.0 make migration to strong authentication seamless for applications. In Identity 1.0, each application that wants to do strong authentication of the user would need to implement some form of strong authentication. And given the traditional siloed approach, that would likely result in each application implementing their own method of strong authentication and more frustration to the user and admin, and more cost to the agency to support multiple methods of strong authentication. Because in Identity 2.0 the user authenticates directly to the Identity Provider (which then issue’s the responder’s device a token asserting the authentication which the applications use to authenticate the user), only a single server in the network needs to be upgraded to strong authentication (the Identity Server). Applications will still authenticate the user using the token / assertion. Hence an agency can upgrade their Identity Provider server from password-based authentication to strong authentication, and the applications pick up the benefits of this strong authentication for free. The applications don’t need to understand anything about passwords or smartcards or biometrics or RSA codes – they just continue to use the same token / assertion.
ONly apply to federal employees… but
“who is this?” - That is “what is your identity” Thank-you
How Certain - Can I trust it, what level of assurance
The date is July 17, 1996. Emergency services personnel from Suffolk County, NY and the United States Coast Guard respond to a report of a catastrophic explosion and the crash of a passenger airliner over the ocean off the southern coast of Long Island. The
initial assumption is a nexus to terrorism. The East Moriches Coast Guard Station is designated as the operations command post, staging area, and evidence collection point. As the incident shifts from response to recovery, personnel from various response disciplines and levels of government stream into the station. Among them is Lieutenant Colonel David Williams of the U.S. Army Reserve. LTC Williams, dressed in his U.S. Army Reserve flight suit, presents identification, enters the site, and assists in the operation by landing helicopters on the designated helipads. On the third day of his work, LTC Williams is questioned concerning his identity and affiliation. Following a brief investigation, LTC Williams is identified as an impostor, escorted from the
property, and charged by the Suffolk County Police.
The events of September 11, 2001 brought to the forefront and interesting dilemma with respect to highly secure and sensitive facilities and major disasters. In particular, when the Pentagon was struck it resulted in a massive response of public safety personnel from fire, EMS, and police. Given the technology used at the time, it was impossible to authenticate and validate emergency responders at a pace necessitated by the disaster. While the majority of emergency responders already had identification cards, their credentials were not recognized at all levels of government or by the various jurisdictions. The incident commanders on site either had to assume that people were who they said they were, or they had to deny or delay access of critical emergency personnel to the crash scene. This same scenario could be applied to any disaster at any secured federal building in any city or state.
The solution to address this is an interoperable PIV card, called the PIV-I, Scenario described in PIV-Interoperable Credential Case Studies
There are many efforts ongoing within the United States to advance the state of Identity Management.
FICAM
Calls on federal agencies to accept credentials issued by non-federal identity providers (e.g. private sector, first responders)
GFIPM
Sponsored by the Department of Justice, NIEF is the largest federation of public safety / law enforcement within the United States
NSTIC
White house initiative to move the Internet at large toward an Identity 2.0 model (e.g. portable credentials, strong authentication)
NIST Cybersecurity Framework
Roadmap highlights authentication as the first of nine different, high-priority “areas of improvement” that need to be addressed through future collaboration with particular sectors and standards-developing organizations.
FirstNet
Lots of questions in RFIs asked about Identity Federation, support of open standards, etc.
Outside of the United States, there are many efforts going on internationally as well. This is not an exhustive list, it is only meant to illustrate that there is a lot of investment going on in this space.
UK, Identity Assurance Programme https://www.gov.uk/service-manual/identity-assurance
Japan
Canada http://www.cio.gov.bc.ca/local/cio/informationsecurity/documents/PS_2012_PDFs/16-S-1035-Pierre_Boucher.pdf
New Zealand, RealME http://www.dia.govt.nz/Services-Identity-Verification-Service-Index
GSMA / World Mobile Congress / Mobile Connect
carriers around the world lining up to be the epicenter of digital identity
MSI investments in Identity Management will follow a phased roadmap. Initial investments in 2014 are focused upon providing centralized credential management and SSO within a single agency by building the core of the identity ecosystem and tokenizing an initial set of MSI applications . Future investments will focus on tokenizing the remaining set of MSI applications, opening up the MSI Identity Ecosystem to third-party applications & developers, the ability to federate identity, as well as extending our already existing strong authentication solution (making it available to a wider range of MSI applications).
The Pillars of the MSI Identity Ecosystem … the main points to drive home when talking with customers:
Centralized credential management that integrates with customers existing active directory
Single Sign-On across MSI apps, SDK available to on-board third-party apps
Enables interoperable identity across other agencies, regions, FirstNet, GFIPM, cloud
Enables apps to move to strong authentication without changes
Mobile Friendly, Cloud Ready
Built on Industry dominant, open standards
How to solve the problem with as minimal user friction as possible is what I live and breathe now. Law enforcement, fire, EMS all have unique requirements for interfacing with their devices.
When is a single factor needed (something I have)
When is 2 factor needed?
-Many of you experience both singlle factor and 2-factor today.
Entering a password to logon is a SINGLE factor authentictaion.
Using your ATM card is two-factor (Need the card and the PIN).
A number of smartphones support mobile wallets that require two-factor (emulated card on phone…. And a PIN). In apples case, no PIN, but your fingerprint (Touch ID).
There are even cases of 3 factor.
Some bankes use 3-Can choose 3. Choose solution best fitted for user group and level of security.
Many IdP (Authenticators) can support multiple factors
Brainwave (EEG) – Very early, Will first responders be able to focus under duress. NeuroSky. InteraXon
Heart Rhythm (ECG) - Falsing and time Bionym’s Nymi
Voice – Easily copied
Fingerprint – Easily lifted (liveliness issues… and hand not always available)
Finger/hand vein
Iris scan –Want to hold your phone to your face?
Retna scan –Want to hold your phone to your face?
Facial scan –Want to hold your phone to your face?
Smartbadge – NFC Yes, On lanyard, built into badge (undercover issues). Shared device
OTP Token – Cumbersome
Wearable –Early but potential
Smartphone - Thinking OOB
Derived credential (must have SE)
Verbally discuss:
There are 3 primary use cases for authentication, and each may require different LoA.
REMOTE ACCESS (CJI requires two factors)
Physical ACCESS (generally requires 1-factor, but depending on what you are accessing may require 2-factor).
Local access (accessing your phone, mobile computer (perhaps while off network) .e.g. out of coverage, on a jet…
Any solution should address all 3. Lets discuss now some new technologies
Most exciting area is biometrics, so that’s what I’d spend time on given the short window of time.
Phenotypic or Behavioral – These biometrics use traits that we develop or acquire over time through our own individual experiences. Examples of these include voice recognition, gait, keystrokes, and gestures. These biometrics are based on measurements and data derived from an action performed by a user and thus indirectly measure some characteristic of the human body.
Genotypic (genetic) or Physical – These biometrics use traits that are genetic based and thus do not change over time. This would include such things as our fingerprints, vein pattern, iris, and even our electrocardiogram. These biometrics are based on direct measurement of parts of the human body.
The human brain is made up of billions of interconnected neurons; the patterns of interaction between these neurons are represented as thoughts and emotional states. Every interaction between neurons creates a minuscule electrical discharge; alone these charges are impossible to measure from outside the skull. However, the activity created by hundreds of thousands concurrent discharges aggregates into waves which can be measured.
Different brain states are the result of different patterns of neural interaction. These patterns lead to waves characterized by different amplitudes and frequencies; for example waves between 12 and 30 hertz, Beta Waves, are associated with concentration while waves between 8 and 12 hertz, Alpha Waves, are associated with relaxation and a state of mental calm. (The contraction of muscles is also associated with unique wave patterns, isolating these patterns is how some NeuroSky devices detect blinks.)
All electrical activity produces these waves (even light bulbs), thus all electrical devices create some level of ambient “noise”; this “noise” interferes with the waves emanating from the brain, this is why most EEG devices will pick up readings even if they are not on a person’s head. Measuring mental activity through these waves is like trying to eavesdrop on a conversation at a loud concert. In the past, EEG devices circumvented this problem by measuring these signals in environments where electrical activity is strictly controlled and increasing the signal strength of the data coming from the brain through the application of a conductive solution.
+ Livliness (brain has to be functioning). Voice can be recorded, fingerprint can be lifted (3D printers can actually print fingers with fingerprints.
Enroll: Enter password twice (maybe 3 times now)
The raw measurements used for keystroke dynamics are dwell time and flight time. Dwell time is the time duration that a key is pressed while flight time is the time duration in between releasing a key and pressing the next key. When typing a series of characters, the time a person needs to find the right key (flight time) and the time the key is held down (dwell time) is specific to that person, and can be calculated in such a way that it is independent of overall typing speed.
One logical and simple extension to single factor password entry is to incorporate keystroke biometrics as a second factor. In this case the keystroke biometric of the user’s password entry is part of the authentication. The keystroke dynamic template is established during password enrollment where users must enter their new password twice (perhaps 3 times now). Every future successful login can use the keystroke dynamic to further define the biometric.
Interestingly, keystroke dynamics can also be used in a very specific form of surveillance; namely employee surveillance schemes. It turns out keystroke dynamics could be used to fight effectively against insider threats. For example cataloguing the history of keystroke dynamics for user accounts can be used to detect whether accounts are being shared (being used by people different from the genuine account owner). Reasons for such an implementation could be verification of users following security procedures (password sharing) or to verify that no software licenses are being shared (especially for SAAS applications).
DOES NOT APPLY to smartphones necessarily, but it gives an idea of how gestures (typing) can be used.
Gestures being driven by gaming… (next generation won’t need remote controls).
What is interesting to note: To avoid privacy issues (i.e. I don’t want my biometric registered with some website… since I can’t change my biometric).
-Keep biometric local (actually never leaves my device. Bioemtic is only used to unlock a secret key).
Its my devices secret key that is actually used to authenticate… but that key is locked and the only way to “unlock” it is by me presenting soemthing I am or something I know.
5% to 10% is the Equal Error Rate (Rate at which False Rejection = False Acceptance).
Describe slide (first part).
This is proven technology, NFC is used by card payments ystems.
Sophistcated cards: Have microprcessor, have memory, have secured environement for cryptographic functions (stores encryption keys, biometrics)
-Supports single factor and mutlifactor
Defined secuirty for Physical access, local device access, and remote services (e.g. CJI access)
Ask, what is the problem?
-Slow? (if having to encrypt or sign emails)
Must have card handy
Cost… like me, already have card. Need money to upgrade card system?
NO: cards can support Proximity, Physcical, and NFC. So new cards can work with old system (e.g. Prximity for existing physicla access, FRAC for portable users… once card).
Solution “concept called card emulation”… put the card away, phone becomes the card.
How does this work with Adams decription. Use the card to get a token for SSO, since not every applictaion will support FRAC/PIV authentictaion mechanisms, nor should they. However, obtain an asseryion with claims on “how you were proofed… i.e. with a PIV or FRAC, and bingo…SSO and federation still works).
You ever wonder “I logged in…. But how does the system know I am still using the computer, portable, or mobile”.
A last Point about biometrics for you to tuck away:
THE NEXT TIME YOU HEAR SOMEONE CLAIM THAT “PRIVACY INVASION TO GIVE UP YOUR BIOMETRIC” know 2 things:
They don’t store your actual biometric, rather a template. Of course malware could intercept a biometric sample. So implementation is important, devices need a secure environemnt, much like a bank vault, to store and process biometrics.
Can’t revoke a biometric
Move to keep LOCAL and secure on device (no back-end)
So…. What is big picture veiw on how biometrics are used:
Click on an application
Luanches communication w/server which indicates “two-facator” needed
Phone then displays “Enter PIN or biometric”
Describe flow.
Question you may be asking “How did I get the secret on my phone”
Answer: That is another 1 hour presentation. But there are ways.
Need PRIMARY Authentication to be frictionless (UX)
Needs to be secure, and meet requirements for Local logon, remote logon and physical access
Must leverage standards and minimize cost
Click on an application
Luanches communication w/server which indicates “two-facator” needed
Phone then displays “Enter PIN or biometric”
Describe flow.
Question you may be asking “How did I get the secret on my phone”
Answer: That is another 1 hour presentation. But there are ways.
