AUTHENTICATION REDEFINED

ISSE 2016 16.11.2016

Libor Neumann | ADUCID s.r.o.

“ON-THE-FLY” MIGRATION OF EID TO ELLIPTIC CURVES CRYPTOGRAPHY

Long-term sustainability of eID ecosystem

• It is impossible to:

• expect usability of current cryptography in following decades

• accept a blackout of any widely used eID ecosystem during its upgrade to new cryptography

Why?

Agenda

• Authentication protocol modification

• Deployment limits

• On-the-fly deployment support

• External authentication service

• Fully automated identifiers management

• Fully automated life-cycle of cyber-identities

• Mutual authentication using asymmetric cryptography

• Universal Cryptographic Protocol

• Independent cryptographic layer

• Built-in security management

• Integrated data channel binding with binding control

Assets

Personal Electronic Identity Guardian

Service Provider Identity Machine

ADUCID external interfaces

Target application or other ICT system

ADUCID

User

ADUCID foundation

‐ Only one framework with provable security features 

‐ Repeated use of the framework for different operations

‐ Security features of the framework are independent on  cryptography

One Abstract Framework

General cryptographic operations

- Encryption E (& Decryption D)- Sign S (& Signature Verification V)

General variables‐ RS – Random String ‐ X  ‐ new secret‐ Y, Z – variables including specified items

Precondition‐ ATS – Authorized Information and Secret (e.g. authorised public keys of 

both sites & private key of the specific site – asymmetric cryptography, authorized shared secret – symmetric cryptography)

UCP Main Principles – published 2011

t

Universal Cryptographic Protocol Note

Site(A) Site(B)

OI0 → Step 1:

← OI1OIx → Optional number

← OIy of (OIx,OIy) pairs

…. ….OI2, RS → Step 2:

← OI3, E(X), S(Y)OI4, S(Z) →

The following communication between A and B is encrypted (andoptionally authenticated)

Step 3:

← UIbUIa → Optional number

…. …. of (UIb, UIa) pairs

← OIend End

UCP sequence description

‐ Random string 

‐ Entropy is defined by implementation and by configuration

‐ Authentication challengeRS

X

‐ Random string ‐ Entropy is defined by implementation and by configuration‐ Authentication challenge ‐ New  authenticated shared secret

Y‐ Y = {authID, OI0, OI1, OIx and OIy pairs, OI2, RS, OI3, E(X), and optional 

values }‐ Authentication & Important values integrity check 

Z‐ Z = {authID, OI0, OI1, OIx and OIy pairs, OI2, RS, OI3, E(X), S(Y), OI4, and 

optional values }‐ Authentication & Important values integrity check 

UCP Variables t

t

‐ Only one framework with provable security features 

‐ Repeated use of the framework for different operations

‐ Security features of the framework are independent on  cryptography

One Abstract Framework

General cryptographic operations

‐ EC Key Agreement

‐ EC Sign S (& Signature Verification V)

General variables‐ DHSS – ECDH Shared Secret‐ X  ‐ new secret‐ Y, Z – variables including specified items

Precondition‐ ATS – Authorized Information and Secret (e.g. authorised public keys of 

both sites & private key of the specific site – asymmetric cryptography)

UCP2 Main Principles - EC

Universal Cryptographic Protocol 2 Note

Site(A) Site(B)

OI0 → Step 1:

← OI1OIx → Optional number

← OIy of (OIx,OIy) pairs

…. ….OI2, DHPuK1 → Step 2:

← OI3, DHPuK2, S(Y) DHSS & X

OI4, S(Z) → calculation

The following communication between A and B is encrypted (andoptionally authenticated)

Step 3:

← UIbUIa → Optional number

…. …. of (UIb, UIa) pairs

← OIend End

tUCP2 sequence description

‐ Elliptic Curve Diffie‐Hellmann (ECDH) Shared Secret

‐ Entropy is defined by EC configurationDHSS

X

‐ X = DHSS

‐ Authentication challenge 

‐ New  authenticated shared secret

Y‐ Y = {authID, OI0, OI1, OIx and OIy pairs, OI2, OI3, DHPuK1, DHPuK2, 

DHSS and optional values }‐ Authentication & Important values integrity check 

Z‐ Z = {authID, OI0, OI1, OIx and OIy pairs, OI2, OI3, DHPuK1, DHPuK2, 

DHSS, S(Y), OI4, and optional values }‐ Authentication & Important values integrity check 

9

tUCP2 Variables

Topology limits• Reused key issue

• Server certificate update

• User certificate update

Situation

• Many users, many service providers

• Server site & client site cryptography migration

• No service blackout

How to deploy?

Protocol update

• Known methods – version identifier

Deploy sequence

• Update of all clients

• Verify if all clients are updated - how?

• Server certificate migration

Server certificate

Smart card ID• New ID card has to be issued and delivered

to every citizen

• Usual ID validity period – 10 years

Deploying sequence

• Update of all relying parties

• Verify if all relying parties support old and new cryptography used by different clients

• Issue and delivery of new certificates to all clients

Client certificate – certification authority with many relying parties

On-the-fly deployment - architecture

Peer-to-peer topology

No reused key

User authenticator – different key set for every service provider

Server site – different key set for every user authenticator

Built-in multi-version support

Version identification

Multi-version backward compatibility

Update from cloud – Apple AppStore, Google Play,…

BYOD support

On-the-fly deployment - tools

Parameter agreement

Parameter check by authenticator

Optional parameter sets

Built-in managementProtocol/parameter enforcement controlled by security management console

On-the-fly enforcement

• Planned

• Event driven

• UCP UCP2 - Different cryptographic operation support (encryption + signature <-> key-agreement + signature)

• Protocol modification is needed -> Multi-protocol environment

• Reused keys complicate/disables on-the-fly deployment

• On-the-fly deployment solution

• Independent paired key sets topology

• Built-in multi-protocol support & parameter agreement

• BYOD + cloud upgrade

• Built-in security management

• Planned deployment

• Emergency deployment

Conclusion

AUTHENTICATION REDEFINED