Development of Digital Identity Systems

Development of Digital
Identity Systems
Presenter: Maganathin Marcus Veeraragaloo
Date: 6th July 2017

• Context – Digital Transformation / Industry 4.0
• Cyber Security evolution to Digital Security
• Identity in a Digital World
• Development of Digital Identity Standards
• Authentication Protocols
• Authentication Technologies
• Conclusion
Agenda

Context – Digital Transformation / Industry 4.0

• Conclusion
Cyber Security is evolving into Digital Security

Cyber Security evolution to Digital Security
Digital Security
Cyber Security
Information Security
IT Security
Physical Security
IoT Security
OT Security
Smart Grid Security
Network Perimeter
Disappearing
Digital Security is the evolution of Cyber Security or
The scope of Cyber Security is evolving into Digital Security

• Cyber Security is evolving into Digital Security
• Conclusion
Agenda

Identity in a Digital World
Identity

Development of Digital Identity Standards
NIST Special
Publications
800-63 Suite
SP-800-63-3
Digital Identity
Guidelines
SP-800-63-3A
Enrollment &
Identity
Proofing
SP-800-63-3B
Authentication
& Life Cycle
Management
SP-800-63-3C
Federation and
Assertions
Identity Assurance Level (IAL): the identity proofing process and the binding between one or
more authenticators and the records pertaining to a specific subscriber
Authenticator Assurance Level (AAL): the authentication process, including how additional
factors and authentication mechanisms can impact risk mitigation
Federation Assurance Level (FAL): the assertion used in a federated environment to
communicate authentication and attribute information to a relying party (RP)

• It provides an overview of general identity frameworks; using
authenticators, credentials, and assertions together in a digital
system;
• Organizations can perform a risk assessment, answer a set of
functional questions, and, based on their responses, be guided to
the most appropriate xAL for their system and users.
• Agencies need to look for requirements and ensures that the
assessment of risks and the available processes and technologies
mitigate that risk and are well aligned.
• Align with commercial markets, promote international
interoperability, and focus on outcomes (where possible) to
promote innovation and deployment flexibility.
NIST-800-63-3

Digital Identity Model – NIST 800-63-3
( Digital Identity Guidelines)

• Arguably the most difficult part of digital identity: strengthening identity
proofing while expanding options for remote and in-person proofing.
• Guidelines clarify methods for resolving an identity to a single person and
enables RPs to evaluate and determine the strength of identity evidence.
• The proofing guidance moves away from a static list of acceptable
documents and instead describes “characteristics” for the evidence
necessary to achieve each IAL.
• Agencies can now pick the evidence that works best for their stakeholders:
what matters is the process behind the presentation.
• This opens the door for a diverse array of proofing options, including
virtual in-person (aka “supervised remote”) and trusted referees (e.g.,
notaries, Certificate Authorities), and offers clearer guidelines on
document checking and address confirmation.
Identity Proofing (SP-800-63A)

• The new guidelines also enable server-side biometric matching and
include a comprehensive set of biometric performance and security
requirements.
• Biometric sensors are common in the devices that so many users carry
daily
• Provide guidelines that can prevent unreliable or weak biometric
approaches from sneaking their way into digital services.
• More options (to include more usable ones) at higher assurance levels.
• Changes Too
• email as a place to send one-time-passwords (OTPs)
• plain old SMS to send OTPs, although SMS is allowable with some risk-based and
security measures
• “token” talk – it’s now “authenticator”
Authentication (SP-800-63B)

• Federation is when the RP and IdP are not a single entity or
not under common administration.
• Federation enables an IdP to proof and authenticate an
individual and provide identity assertions that RPs can accept
and trust.
• Provides greater detail on how assertions should be used, and
includes a host of privacy-enhancing requirements that can
make federation appealing to users.
Federation (SP-800-63C)

• Conclusion
Agenda

• OAuth 2.0 enables applications to access resources on behalf of a specific user.
This is why the OAuth protocol has a resource server — a policy enforcement
point that is likely either an API gateway or a reverse-proxy Web access
management (WAM) system.
• The OAuth access and resource servers work in concert to provide access to
resources via a scope (see the Scopes section) entitlement request by the
application.
Authentication Protocols
• Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML
standard for exchanging authentication and authorization data between security
domains.
• SAML 2.0 is an XML-based protocol that uses security tokens containing
assertions to pass information about a principal (usually an end user) between a
SAML authority, named an Identity Provider, and a SAML consumer, named a
Service Provider.
• SAML 2.0 enables web-based authentication and authorization scenarios
including cross-domain single sign-on (SSO), which helps reduce the
administrative overhead of distributing multiple authentication tokens to the
• Connect is about authentication — providing an ID Token for interoperable access
to cross-domain relying.
• The Connect protocol leaves the policy enforcement to the relying party — just
like SAML does.

• Is a means of expressing specific entities in a system by URL path elements.
• REST is not an architecture but it is an architectural style to build services on top
of the Web.
• REST allows interaction with a web-based system via simplified URLs rather than
complex request body or POST parameters to request specific items from the
system.
• REST stands for Representational State Transfer. It relies on a stateless, client-
server, cacheable communications. In most cases it is used with the HTTP
protocol.
• JavaScript Object Notation or JSON (/ˈdʒeɪsən/ JAY-sən), is an open-standard file
format that uses human-readable text to transmit data objects consisting of
attribute–value pairs and array data types (or any other serializable value). ...
JSON is a language-independent data format.

Source: https://fidoalliance.org

Authentication Technologies
Blockchain and Digital Signatures
• Usually a digital signature is made using the private key of the owner.
Whoever wants to verify the signature can do so using the corresponding
public key.
• Suppose a company wants to accept Bitcoins for its trades. Now, because of
security reasons, the company would not want that only a single employee will
have access to the company's Bitcoin wallet's password. Any transaction
should need approval from more than one employees of the company. A multi-
signature address is created for that purpose.

Blockchain and Digital Signatures…continued
• A multi-signature address is an address associated with more than one Elliptic Curve
Digital Signature Algorithm (ECDSA) private keys. So, in an m-of-n address, when a
Bitcoin address is generated, it is associated with n private keys. And, at least m private
keys will be required to make a transaction possible.
• This concept can be used in making digital signatures. One can create a multi-signature
m-of-n address using n private keys and use that to record digital signature of
documents in a blockchain. Anyone can verify the digital signature using public keys, but
to make the digital signature one would need at least m private keys, out f n private
keys associated with the multi-signature address.

Public Key Infrastructure - Digital Signatures
• When two hosts want to transfer sensitive data between them, they use an encrypted communication. Both the
hosts first connect to each other, authenticate themselves and after that an encrypted connection is established,
using which sensitive data are transferred.
• If a host wants to authenticate itself to the other host, it needs to prove its identity. Normally, public key
cryptography is used for that purpose. Each host possesses a private-public key pair. And, to establish an
encrypted connection, they share their public keys to each other.
• But, one has to confirm that the shared public key indeed belongs to the sender. Public Key
Infrastructure or PKI is an arrangement which is used for that purpose. It binds public keys with corresponding
identities through registration and issuance of certificates and using centralized authority called Certificate
Authority or CA. PKI consists of set of roles, policies and procedures to create, manage, distribute or revoke
digital certificates.

Public Key Infrastructure - Digital Signatures
• Certificate Authority - A Certificate Authority issues a digital certificate to an entity. The issued digital certificate
is signed with the private key of the CA, so that it is not tampered with. When a host gets a digital certificate of
another host, it checks with the corresponding CA to make sure it is an authentic one.
• Registration Authority - When an entity requests for a digital certificate, the Registration Authority verifies the
identity of the entity to make sure the digital certificate is not mis-issued.
• Central Directory - A Central Directory is a central location where public keys are stored and indexed, so that they
can be retrieved at the time of verification of digital certificates.
• Certificate Management System - A Certificate Management System manages access to stored certificates and
the delivery of the certificates to be issued.
• Certificate Policy - It consists of policies of digital certificates.

Block Chain

Conclusion
Trusted Digital
Identity
Source: https://securityintelligence.com/

Development of Digital Identity Systems

More Related Content

What's hot (20)

Similar to Development of Digital Identity Systems (20)

More from Maganathin Veeraragaloo (20)

Recently uploaded (20)

Development of Digital Identity Systems