jordi Íñigo universidad de murcia, november 17, 2011 segurity and pki

Jordi Íñigo

Universidad de Murcia, november 17, 2011

Segurity and PKI

Jordi Íñigo – November 2011

WWW.SAFELAYER.COM

Safelayer Secure Communications, S.A.

• Software vendor of PKI and signature and authentication systems since 1999

• EMEA and Latam• Software on DNIe,

FNMT, NATO, CNI, BdE, BBVA, Repsol…

2


WWW.SAFELAYER.COM

Basic crypto tools: symmetric crypto

• Local protection‒ Protect against manipulation

‒ Protect against copy

‒ Tools: symmetric cryptography (symciphers, hashes and MACs)

‒ Purpose: local drive, backups

3

encrypted msg = Kx (msg) / msg = Kx−1 (encrypted msg)

signature = hash(msg) / signature = hash(msg)

secret signature = hash(K + msg) / secret signature = hash(K + msg)

encrypted msg = Kx (msg) / msg = Kx−1 (encrypted msg)

signature = hash(msg) / signature = hash(msg)

secret signature = hash(K + msg) / secret signature = hash(K + msg)

Kx ≡ symkey shared by endpoints/endusers


WWW.SAFELAYER.COM

Basic crypto tools: public key crypto

• Transmission protection‒ Signature for message integrity verification, author authentication and

non-repudiation of authority

‒ Encryption for message confidenciality

‒ Tools: asymmetric or public key cryptography (RSA, etc.)

‒ Purpose: mail (S/MIME), http (https), on-line transactions

4

encrypted msg = PBKx(msg) / msg = PVKx(encrypted msg)

signed msg = PVKx(msg) / msg = PBKx(signed msg)



PBKx ≡ public key of user X (known to user Y)PVKx ≡ private key of user X


WWW.SAFELAYER.COM

Basic “PKI” (Public Key Infrastructure)

• How we know for sure that PBKx corresponds to the (PVKx of the) user X?

‒ We must be sure since the owner of PVKx can decrypt what we encrypt with PBKx

‒ We must be sure since the owner of PVKx can sign what we verify as signed by x (PBKx)

• Public Key Infrastructure

‒ Is a (particular) solution to handle how PBKx are made public (safely) to each member (of a group)

5


WWW.SAFELAYER.COM

Basic “PKI”: architecture (1/3)

• PBKx are tighted together with an identifier of the owner* of the PVKx encapsuled in “protected file”: X.509 Certificate

• The protection of this file is done… by signing it!

• PBKPKI is known by all (members of the group)

6

*) Distinguished Name



cert content = PBKx + DN*

certx = PVKPKI(cert content) / cert content = PBKPKI(certx)

cert content = PBKx + DN*

certx = PVKPKI(cert content) / cert content = PBKPKI(certx)


WWW.SAFELAYER.COM


• Who owns PVKPKI? the Certification Authority (CA (*))

‒ Everybody knows (and trust) the CA

‒ Everybody knows (and store safely) the PBKCA (*)

• Now I do not have to keep PBKX from user X safely: it is just OK to download from a (even untrusted) repository

7

cert content = PBKuser X + DN

certx = PVKCA(cert content) / cert content = PBKCA(certuser X)

cert content = PBKuser X + DN

certx = PVKCA(cert content) / cert content = PBKCA(certuser X)

*) from now on, we will call PVKPKI and PBKPKI as PVKCA and PBKCA

e.g. signature:msg = PBKuser X(signed msg) + PBKCA(certuser X)

(PBKuser X + DNuser X)

e.g. signature:msg = PBKuser X(signed msg) + PBKCA(certuser X)

(PBKuser X + DNuser X)


WWW.SAFELAYER.COM


• Usually CA chain its certificates to a “mother CA”: root CA‒ Some CA are “users of” other CA: subordinate CA

• There are other authorities as well:‒ TSA (Time Stamping Authorities)‒ VA (Validation Authorities)‒ RA (Registration Authorities)‒ …

8

e.g. signature)

e.g. signature)

PBKsubor CA

message

certuser X

PBKroot CA

(or atack the weakest link)

Chain of Responsability


WWW.SAFELAYER.COM

Chain of responsability: Actors

• Actors‒ Cryptographers

‒ Protocol Developers

‒ Software Developers

‒ System Integrators

‒ Security Officers

‒ System Administrators

‒ System Owners

‒ End Users (info issuers)

‒ End Users (info consumers)

‒ Other interested third parties (hackers, competitors, rivals, etc.)

10


WWW.SAFELAYER.COM

Chain of responsability: Actors• Cryptographers

state of the art technology, flaws, public algorithms

• Protocol Developers state of the art technology, flaws, public protocols, protocol election

• Software Developers (systems: end users, service providers, “pki’s”) coding skills, evaluation of code, use public code, knownledge, protocol

election, algorithm election

• System Integrators (systems: service providers, “pki’s”) technology knownledge, budget, schedule, software election

• Security Officers (systems: end users, service providers, “pki’s”) technology knownledge, schedule

• System Administrators (systems: ~end users, service providers, “pki’s”) technology knownledge

• System Owners (systems: end users, service providers, “pki’s”) priorities, budget, market value

• End Users technology knownledge and levelling, commitment (S.O. protection)

• End Users, Other third parties (hackers, competitors, rivals, etc.) steal knowledge, steal money, harm honorability, trustiness, etc.

11


WWW.SAFELAYER.COM

Cryptographers

• Cryptography algos have a limited life expectancy. Cryptographers find flaws in previous designs: the rest (developers, integraters, protocol designers...) must keep the pace ‒ e.g. DNIe issues dual certificates, SHA1 based for backwards

compatibility and SHA2 based to improve time resistance

• Optimize attacks or develop new attack techniques‒ Massively parallel computing (thread over short keys)‒ Quantum computing (thread over some protocols)

12


WWW.SAFELAYER.COM

Symmetric Algorithms

• Ciphering Algorithms in use:‒ AES-128 / AES-256 (128/256 bits key)

‒ 3DES (112/168 bits key)

• Hash‒ SHA-1 (160 bit hash)

‒ SHA-2 (224, 256, 384 and 512 bits hash)

• MAC‒ HMAC (SHA-1, SHA-2 256…)

NOTE: look for NSA Suite B (National Security Agency’s recommended algorithms)

13


WWW.SAFELAYER.COM

Public Key (asymmetric) algorithms (1/3)

• Signing algorithms in use:‒ RSA (1024, 2048 and 4096 bits keys)

‒ ECDSA (224, 256, 386 bits keys)

• Encryption algorithms in use‒ RSA (1024, 2048 and 4096 bits keys)

‒ ECDH (224, 256, 386 bits keys)

NOTE: PBK crypto is slower than K crypto we chain both

NOTE: look for NSA Suite B as well

14


WWW.SAFELAYER.COM

Protocol developers

• They must fully understand cryptographic algorithms, their parameters and their limits of operation‒ protocols

• paddings

• initialisation vectors

• downgrade agreement parameters (compatibility with insecure parameters)

‒ secret/private key• randomness

• secrecy (throughout lifecycle)

• access control

‒ WiFi WEP (Wired Equivalent Privacy) flaw: it is possible to “read” otherwise encrypted data

‒ TLS 1.0 flaw: it is possible to “read” otherwise encrypted data (https connections)

‒ etc.

15


WWW.SAFELAYER.COM

(PKI related) Software developers

• Code development‒ Best practices, “secure” programming, provable programming‒ Code Access Control‒ System “partitioning” in smaller parts

• PVK handling• PVK operation and auditing

‒ Third party evaluation: ISO-15408 “Common Criteria”• Well defined and internationally agreed evaluation and certification• Code revision• (Security) Functions description• Procedure auditing• ...

16


WWW.SAFELAYER.COM

End Users, integrators, officers, sysadmins…

• All PKI are not the same‒ Use one that suits you (...and you can afford)

• Security is difficult to validate‒ enforce it where possible

• PKI is dificult to understand‒ Deep understanding of the system/project for lead actors

(integrators, officers)‒ Use software fool proof (e.g. signature workflow instead of

generic signature products where possible)• Integrators “of security” (no only “software/system integrators”)• End Users’ systems must be trusted

17

system deployment


WWW.SAFELAYER.COM


• All PKI are not the same‒ PKI is ruled by the Certification Policy

• Certification Policy defines the “rules” of that PKI‒ Algorithms‒ Validity period (of certificates, keys)‒ Procedures for End Entity (End User) enrollment‒ PVK repository (HSM or not)‒ Revocation procedures‒ Key renewal procedures‒ etc.

• Can I select it?‒ Root CA cert selection

18

system deployment

certificate = PVKCA(PBKuserX + DNuserX)certificate = PVKCA(PBKuserX + DNuserX)


WWW.SAFELAYER.COM


• Security is difficult to validate‒ enforce it where possible: use HSM (Hardware Secure Modules)

• HSM for CA, VA, TSA or even https servers, transaction servers• HSM for end users (smart card)• Some HSM properties:

‒ PVK never abandon the (physical) safe box

PVK are generated, operated and deleted in-side‒ PVK are generated from real random numbers‒ PVK physical/logical access control‒ Safebox with physical attack countermesures‒ API is small (easily verifiable) [PKCS #11]

19

system deployment


WWW.SAFELAYER.COM


• PKI is a bit dificult to understand to non technical people (...)‒ Deep understanding of the system/project for lead actors

(integrators, officers) at least is a must‒ Prescribe use of software fool proof where applicable

• (e.g. signature workflow instead of generic signature products where possible)

‒ Educate end users, team them up: don’t force security...

20

system deployment


WWW.SAFELAYER.COM


• End Users’ systems must be trusted‒ PKI and cryptography is useless with tampered end points‒ HSM only protect 50% of the endpoint (PVK custody and op)‒ End points must be securely administered (as a whole)‒ End points must be physically protected

• e.g. EAC* ePassport‒ the whole endpoint (the

EAC ePassport) deployed in an HSM (contactless Smart Card)

21

system deployment

*) EAC: Extended Access Control, or 2on phase


WWW.SAFELAYER.COM

Muchas gracias:

Jordi íñ[email protected]

jordi Íñigo universidad de murcia, november 17, 2011 segurity and pki

Documents

kx msg msg

pvkxencrypted msg

pbkxmsg msg

pvkxmsg msg

hashk msg secret signature

pbkpkicertxjordi igo

endpointsendusersjordi

pkijordi igo