Transcript Crypto et PKI

From encryption with symetric key to private and public keys, from keys
to certificates and open PKI architectures … PKIX (X509v3)
CRL
version
Issuer's signature
algorithm ID
Issuer's X.500
name
Date & time of
this update
Date & time of
next update
Certificate
serial
number
Certificate
serial
number
Revocation
date
Certificate
serial
number
Revocation
date
Revocation
date
P
IPRA
PCA
CA
CA
Revoked
certificates
Issuer's private
key
user
CA
user
PCA
PCA
CA
user
CA
user
user
user
The PEM CA hierarchy
X.509 v2 certificate
Public / Private Key Usage
•Encryption: message confidentiality
•Digital signatures: message integrity, non-repudiation
•Keys problems: key spoofing, is this really your public keys
–Keys security, Keys management: distribution & revocation, ….
–=> Public Key Infrastructure & certificates X509v3
• PKI Public Key Infrastructure implementation,
– security requirements, complexity, … + X509 interoperability ?
17/07/2015
Crypto, PGP and PKI Overview
1/
CA
user
Authentication – Encryption – Digital Signature needs
symetric key (Security Box File) - PGP – other tools (Security Box Mail) Is it the right Alice X sending the Mesagge A2B
To right BoB X and only to Bob ?
Message X2Y
Message X2B?
Message A2B ?
Is it Alice A writing and sending a
Message A2B from Alice to Bob B
Message A2B ?
Is it Bob B and only Bob B Getting And reading
the right Message A2B from Alice A to Bob B
AliceX ?
Who is Alice A ?
Bob Y ?
How to prouve that it’s really the original message A2B
From the right Alice A to the right Bob and only to Bob B
From thechnical an legal points of view
Who is Bob B ?
Message A2B
Message A2B
Alic A
17/07/2015
Bob B
Crypto, PGP and PKI Overview
2/
Authentication – Encryption – Digital Signature needs
Is it the right Alice X sending the Mesagge A2B
To right BoB X and only to Bob ?
Message X2Y
Message X2B?
Message A2B ?
Is it Bob B and only Bob B Getting And reading
the right Message A2B from Alice A to Bob B
Is it Alice A writing and sending a
Message A2B from Alice to Bob B
Bob Z ?
AliceX ?
Message X2Y
Bob Y ?
How to prouve that it’s really the original message A2B
From the right Alice A to the right Bob and only to Bob B
From thechnical an legal points of view
Message A2B
Who is Alice A ?
Is it still Alice A
Who is Bob B ?
Is it still BOB B
Alice A
17/07/2015
Message A2B
Bob B
Crypto, PGP and PKI Overview
3/
•
Authentication – Encryption – Digital Signature needs
symetric key (Security Box File) - PGP – other tools (Security Box Mail) Symetric key: Security Box File
–
–
–
•
PGP : strong Authentication, encryption & Digital signature but:
–
–
–
–
–
–
–
•
Limitation about the number of users envolved in the web of trust,
No strong warranty between the keys ans the identity of the users, if …
Necessity to send the public key to all other user,
Difficulty to revocate a key and to inform all users
Neccessity to install the software and to manager the users keys
Individual safe backup of the keys
Not easy to for « usual » users or no frequent use, risk to forget to use it !
• ++ can be used not only for email but also for files !
Security Box Mail:
–
–
–
•
no digital signature,
risks for untrusted people to get the key,
Necessity to change too often then key …
More user-friendly than PGP, possibility to force a list of destination to encrypt,
The same other default as PGP + software to implement, ? X509 application interoperability ?
The risks of a propriatary solution: ? A backdoor of flaw / lack of implementation
PKI: may be nice for users, on the paper and for vendors, software to implement but :
–
–
Needs a hight secured architecture and certificates generation outsouring
Expensive, the project implentation must be a limited prototype (500 users) , but don’t think about for less
than 1 or a few thousand of users, the project implemetation may cost more than hardware and software
– lack of visibility about successfull projets, Not only for email !!
– Certificates link to an emailer and email, or to an USB key with MS OS
17/07/2015
Crypto, PGP and PKI Overview
4/
The problem: usurpation, interception & modification,
Oscar: thte Man In The Middle – MITM:
Interception, spoofing & usurpation
Alice
Oscar
Internet
Original Alice message
Bob
Ah ! A message from Alice
Ah ! THE message FROM Alice
(alterated by Oscard
Messages with spoofers signature
Oscard !
1) I’ll pretend to be Alice
2) I’ll intercept and modifie Alice message
3) I can read and modify Alice message
17/07/2015
Crypto, PGP and PKI Overview
5/
PGP Web of Trust limits
•
PGP Users need PGP software, to generate Private and Public keys, and
–
–
–
–
–
To protect the Private Key and distribute the public Keys
To verify and evaluate others public Key validation with Fingerprint or direct contact: check
by phone the FIngerprint
To manage the problem of revocated Keys and
To take care about the MITM risk (OSCAR pretending to be Bob):
Oscare can create Private and Public keys with the apparent identity from Alice:
Christ or more obviously Fred could find Alice versus Oscar Public key
Certificates revocation to manage by users !
Alice,
Bob,
Elvis,
Christ
Public keys
Bob
Alice
Internet
(1) Web of trust ABCE
Elvis
17/07/2015
Alice,
Bob,
Elvis,
Christ
Public keys
Internet
i
i
Chris
If Alice keyring set is compromised,
She should revocate her keys,
Generate a new one,
But how to inform who ?
How who will know this
Alice,
Bob,
Elvis,
Christ
Public keys
Crypto, PGP and PKI Overview
l i
Fred
(2) Web of trust CFXYZ
Alice,
Bob,
Elvis,
Christ
Public keys
6/
Crypto, PGP web of trust and limits => PKI
Alice
Oscar
Internet
(Oscar)
TMITM
Bob
Bob's
FTP
server
The Man In the Middle
Bob
Bob
Alice
PGP Web of trust
For a small community
With perfect keys management
17/07/2015
Internet
Elvis
Alice
Internet
Chris
Chris
But www & enterprise limits:
Web of Trust limits and
Problem of Key’s Revocation !
Crypto, PGP and PKI Overview
Elvis
7/
Conventional cryptography & public key encryption
•
•
•
Conventional Cryptography or secret-key or symmetric-key encryption
DES is an example: Data Encryption Standard
The key share is a problem !
• Public Key encryption
- Elgama (Taher)
- RSA (Ron Rivest,
Adi
Shamir,
Leonard Adleman)
-DSA
Digital Signature
Algorithm
(David Kravitz)
17/07/2015
Crypto, PGP and PKI Overview
8/
Simple Digital signature
•
PRIVATE Key signing, send to … PUBLIC key verifying
17/07/2015
Crypto, PGP and PKI Overview
9/
Encryption & Decryption session key, PGP example
•
PGP combines some of the best features of both conventional and public key cryptography: hybrid cryptosystem
•
PGP crates a session key, a one-time-only secret key,
Plain text is encrypted with session key, Session key is encrypted with PUBLIC Key
•
The recipient’s copy of PGP uses his PRIVATE key
17/07/2015
Crypto, PGP and PKI Overview
10 /
Hash Function
•
As long as a secure hash function is used, no may to take someone’s signature from one
document and attach it to another, or to alter a signed message in any way
17/07/2015
Crypto, PGP and PKI Overview
11 /
a PGP Digital certificate
•
•
The task of establishing whether a public key truly belongs to the purported owner
A digital certificate consist of 3 things:
–
–
–
A public key
Certification information (« Identity » information about the user
One or more digital signature (to state that the certificate information has been attested to by
some other person or entity)
17/07/2015
Crypto, PGP and PKI Overview
12 /
PGP certifiate and PGP X509 certificates
17/07/2015
Crypto, PGP and PKI Overview
13 /
Secret Key (S) = private Key and Public Key: Encryption & encoding
•
•
Message encryption using a secret key (S) to encode the message and
a public key (P) to encode the secret key
P
S
P
S
P
Message
Message
P
S
P
P
S
S
User’s computer
P
P
P
The Secret private Key is encoded,
So even if stollen from compter,
It is protected by the passphrase:
Chose a strong long passphrase mixing
characters, ponctuation, numbers
17/07/2015
P
P
Crypto, PGP and PKI Overview
14 /
Public Key => digital signature
•
Creating a digital signature with the Public Key
Hash
function
Message
P
17/07/2015
Crypto, PGP and PKI Overview
15 /
Public/Private keys – Encryption Mode
•
•
Many users can encrypt for Bob but users need Bob’s Public Key
Only user Bob can Decrypt with his Private Key
?
? Private Key Validation / Protection
Web of Trust ? MITM ?
P
Bob’s Public Key
Distributed to users & validated by users
Plain text
Encrypt
S
Bob’s Private Key (Secret)
Decrypt
cyphertext
System / user A
Plain text
Système D
Encrypt
How can users be shure about
- Bob’s Private Key
- Bob’s Public Key
- is it Bob’s Keys ?
System / user B
Plain text
Plain text
Encrypt
System / user C
? Public Key distribution
? Public Key Validation /
Web of Trust ? MITM ?
17/07/2015
? Public Key Revocation
Web of Trust ?
Crypto, PGP and PKI Overview
?
P
Bob’s Public Key
16 /
Public/Private S Keys – Authentication Mode: is it Alice message ?
•
•
No confidentiality; but proof of origin … if it’s really Alice’s Private Key
All may decrypt … but all need Alice’s not revocated public Key
P
Alice’s Public Key distributed
To users
?
S
Alice’s Private Key (Secret)
Plain text
Encrypt
Decrypt
cyphertext
System / user A
Plain text
Système B
Decrypt
Plain text
Système C
Decrypt
?
P
Alice’s Public Key
17/07/2015
Plain text
? Public Key distribution
Système D
? Public Key Validation /
Web of Trust ? MITM ?
Public
Key Revocation
Crypto, PGP and? PKI
Overview
Web of Trust ?
17 /
Public / Private Keys – Digital Signature
S
•
•
Private Key Secret – kept protected; no usually backup or archived + passphrase
Public Key – archived for verification of old signatures
P
message
Alice
S
hash
hash
digest
digest
decrypt
digest
encrypt
P
Bob
Same ?
Yes/no
Alice’s Public Key
Alice’s Private Key (Secret)
P
Bobs’s Public Key
Unsused for signature,
17/07/2015
Crypto, PGP and PKI Overview
But neccessary to allow Bob to Decrypt !
18 /
Basic public-key cryptography message formats and a basic certificate
Message
Message
Message
S
P
S
P
P
Signed
Message
S
P
Encrypted
Message
S
Signed and Encrypted
Message
Subject identification
information
Subject
public key
CA identification
information
P
CA's private key
17/07/2015
Crypto, PGP and PKI Overview
19 /
A strong PKI Process to generate and manage certificates
User request for a user certificate to a Local Registration Authority -LRA (1). The request is sent to a Certification Authority
(2) deliverying after checking a certificate (3).
When accessing to a secured application, the CA request the certificate, transmit it to the validation authority Authority (4)
for validation (5).
Revocation control
Certification
Authority
Delivery
rules
Certificats
Revocation
List
2
Local Registration
Authority
Request
transmission
3
5
1
•Certificates
Drawing up
•Keys delivery
Certificates
request
Authorization
Validation
Authority
Application
USER
17/07/2015
5
Certificates control
Crypto, PGP and PKI Overview
20 /
PKI components and flows
17/07/2015
Crypto, PGP and PKI Overview
21 /
PKI within an Open architecture: a complex hierachical organization
An open www PKI requires 2 CA levels (1 et 2), at least, and a local Registrery Authority (3) Once
the Certificates are delivered (4), it’s up then to use them (5). The external entreprise must be able to
check them about validity (6) and to process a notary act and transmission backup. Une PKI mondiale
requiert deux niveaux d’autorité de certification (1 et 2) et un réseau d’autorité d’enregistrement (3). Une fois les certificats délivrés (4), il
s’agit de les exploiter (5). La place de marché doit alors vérifier leur validité (6) et procéder à la notarisation et à l’archivage des transactions.
Validation
Notary act
& backup
6
Root CA
1
CA
2
RA
3
7
« extrenal » enterprise
- market place -
Certificate
4
Private Key
Certificate
request
5
Certificate
« inside » enterprise
Signed digital transaction
17/07/2015
Crypto, PGP and PKI Overview
22 /
Without and with PKI B2B busisines can avoid PKI
With PKI
Enterprise
CA Certification Authority
Control
Mail
server
WEB Server
Certificates
Delivery
VPN Ipsec With certificate
SSL v3 Autehtication
S/MIME mail encryption
Enterprise
•Secure ID Card
delivery
• Encryption
symetric Keys
off line exchange
• Secure
ID Card
• VPN client
• Symetric
Key
17/07/2015
encryption
Without PKI
Enterprise
Mail
server
WEB Server
Crypto, PGP and PKI Overview
ID Card
Authentication
VPN Ipsec
Symetric Key
Email encryption
23 /
? Questions about PKI ?
17/07/2015
Crypto, PGP and PKI Overview
24 /
VERS UNE SÉCURITÉ GLOBALE ET UNIFORME
•
Appliquée à tous les flux HTTP, l'association des infrastructures à clés publiques et des solutions d'authentification unique offre aux platesformes de places de marché un cadre global pour la sécurité.
17/07/2015
Crypto, PGP and PKI Overview
25 /
LA SÉCURITÉ, PREMIER FREIN À L'ESSOR DE L'EPROCUREMENT
•
La sécurité des transactions est un obstacle majeur pour le passage à l'eprocurement. L'absence de standards, les coûts et le manque d'expérience des
fournisseurs sont aussi relevés.
17/07/2015
Crypto, PGP and PKI Overview
26 /
LE MARCHÉ MONDIAL DE LA SÉCURITÉ
•
LE MARCHÉ MONDIAL DE LA SÉCURITÉ
En 2000, les antivirus, les coupe-feu et l'administration de la sécurité tiennent
le haut du pavé de la sécurité logique. En 2005, les VPN et les PKI devraient
rejoindre ce peloton de tête.
17/07/2015
Crypto, PGP and PKI Overview
27 /
Infrastructure – Certificate Distribution
17/07/2015
Crypto, PGP and PKI Overview
28 /
Infrastructure – Certification Validation
17/07/2015
Crypto, PGP and PKI Overview
29 /
Infrastructure – Validation Path
•
17/07/2015
Crypto, PGP and PKI Overview
30 /
X509 Certification path and general hierarchy with cross-certificates
•
A certification
path from
Alice
Alice
CA X's public key
Subject ID info
Subject
public key
ID info for CA X
Certificate 2
Subject ID info
Certificate 1
to Bob
Subject
public key
ID info for CA Y
= CA
= End user
Bob's ID info
Bob's
public key
ID info for CA Z
B
Certificate 3
I
C
D
F
E
a b c d
17/07/2015
A
G
P
J
H
e f g h
K
i
M
L
j k l
Crypto, PGP and PKI Overview
N
Q
O
m n o p
R
T
S
q r s t
U
V
u v w x
31 /
CA Hierarchical model
17/07/2015
Crypto, PGP and PKI Overview
32 /
Outsourced CA to communicate with partners and customers
•
Standalone Root
17/07/2015
Crypto, PGP and PKI Overview
33 /
Standalone BigCorp « inside »
•
BigCorp Root
17/07/2015
Crypto, PGP and PKI Overview
34 /
Standalone BigCoorp certificates and outside imteroperability
17/07/2015
Crypto, PGP and PKI Overview
35 /
My certificates from …
Certificates
Not only
about Email
But …
17/07/2015
Crypto, PGP and PKI Overview
36 /
Inside BigCorp
•
BigCorp and inside organisation
17/07/2015
Crypto, PGP and PKI Overview
37 /
Request New Certificate
•
example
17/07/2015
Crypto, PGP and PKI Overview
38 /
Root Revokes Certificates
•
Example
17/07/2015
Crypto, PGP and PKI Overview
39 /
CA Certificates, hierarchical or network infrastructure
17/07/2015
Crypto, PGP and PKI Overview
40 /
S/MIME and PGP
17/07/2015
Crypto, PGP and PKI Overview
41 /
Email client can use S/MIME or PGP
17/07/2015
Crypto, PGP and PKI Overview
42 /
Web broswer use SSL to secure www connection, and can download
S/MIME / X509 certificates
17/07/2015
Crypto, PGP and PKI Overview
43 /
Email Client can plug in a proprietary Secure Email solution,
but email software can manage encryption and S/MIME certificates
•
Proprietary email secure solution:
– Distribute the software with risk of flaw / backdoors
– Need to manage Key distribution and revocation
17/07/2015
Crypto, PGP and PKI Overview
44 /
Email client can get a Certificate from an authority
•
Getting a certificate needs a « secured transaction » but refere to MS
certificates obtained … for virus by X !
17/07/2015
Crypto, PGP and PKI Overview
45 /
17/07/2015
Crypto, PGP and PKI Overview
46 /
Protocols brief History
•
•
•
•
PGP Pretty Good Privacy Philip Zimmermann 1991 Command line PGP
S/MIME Secure Multipurpose Internet Mail Extension proposed by RSA
IETF S/MIME working group 1995 (Internet Engineering Task Force)
S/MIME v3 IETF standard in July, 1999
–
–
–
–
•
OpenPGP (PGP/ MIME) http://www.omc.org/smime-pgpmime.html RFC 2440
–
–
RFC 1991 – PGP Message Exchange Formats
RFC 2015 MIME Security with Pretty Good Privacy
–
PEM Privacy Enhanced Mail 1980 symmetric encryption RFC 1421-1424
• Flawed design, vulnerability (interception ?)
MOSS MIME Object Security Services TIS/MOSS7.1 56-bit DES,
PKCS#7 Public Key Cryptography Standard #7 adapted from PEM RFC 2315
CMS Cryptographic Message used with S/MIME . RFC 2630
XML Extensible Markup Language 2001 based standard and messaging protocol « Security
Assertion Markup Language (SAML)
–
–
–
–
•
•
RFC 2630 Cryptographic Message Syntax
RFC 2633 S/MIME v3 Message Specification
RFC 2632 S/MIME v3 Certificate Handling
RFC 2631 – Diffie-Hellman Key Agreement Method
SSL Secure Soket Layer secure connections between web client and server
PKI Public Key Infrastructure X509v3 based digital dertificates
17/07/2015
Crypto, PGP and PKI Overview
47 /
Algorthms in use
•
•
•
•
Blowfish: one of the fasted, variable key from 32 to 448 bits
DES Data Encryption Standard 56-bit key adopted/ DoD … but cracked
IDEA International Data Encryption Algorithm 128-bit key
3DES Tripple DES algorithm applies DES 3 times with separate keys, slow
17/07/2015
Crypto, PGP and PKI Overview
48 /
Digital Certificates
•
•
« an attachment to an electronic message used for security purposes. The most
common use of a digital certificate is to verify that a user sending a message is
wwho he or she claims to be, and to provide the reciver with the means to
encode a reply »
CA: Certificate Authority provides X509 certificates
17/07/2015
Crypto, PGP and PKI Overview
49 /
Basic PKI Characteristics
•
Certificate information
•
What data is contained in the certificate? Is it predefined, or can the certificate hold any kind of information?
•
CA arrangement
•
Are the CAs arranged in a strict hierarchy, or is the PKI unstructured?
If unstructured, does the PKI use a web of trust or some other mechanism?
•
CA  Subject  User relationship
•
Are these three distinct entities? How well does each know the other?
For example, is the subject an employee of the CA? Is that a requirement?
•
CA  Subject  User trust relationships
•
Where the entities are distinct, what is the degree of trust that they must place in each other?
Who assumes the most liability in different situations?
•
Certificate validation method
•
Are certificates validated online, every time they are used or does the certificate contain a validity period, or both?
If online, how are bandwidth issues addressed? If offline, how are CRL issues addressed?
•
Certificate revocation method
•
Is the revocation status of a certificate provided online or via a CRL?
If CRLs are used, how are size issues and the time-granularity problem addressed? How do the validity periods of the CRLs relate to the
validity periods of their certificates?
•
Identity vs. credential certificates
•
Does the PKI serve only as a means of identifying the public keys of entities, or can it also be used for credentials such as authorizations,
permissions and other non-entity attributes?
•
Irrefutability and strong authentication
•
Do the users of the PKI have a way of showing that a signature was indeed generated by a particular subject?
•
In-band vs. out-of-band authentication
•
How much out-of-band authentication is required for the operation of the PKI?
•
Anonymity
•
Does the PKI provide its users with any anonymity? Are irrefutability and strong authentication diminished?
17/07/2015
Crypto, PGP and PKI Overview
50 /
X509 v3 Certificate
•
X500 LDAP compatibility …
X.509v1 CRL format
The X.509 version 2 certificate
Certificate
version
Certificate serial
number
CA's signature
algorithm ID
CA's X.500
name
Validity
period
Subject's
X.500 name
Subject's public
key information
Issuer unique
identifier
Subject unique
identifier
P
17/07/2015
CRL
version
Issuer's signature
algorithm ID
Issuer's X.500
name
Date & time of
this update
Date & time of
next update
Version
2 only
CA's private
key
Certificate
serial
number
Certificate
serial
number
Revocation
date
Certificate
serial
number
Revocation
date
Revocation
date
P
Crypto, PGP and PKI Overview
Revoked
certificates
Issuer's private
key
51 /
PKI : A progressive-constrained trust chain ?
D trusts E
subject to
conditions X
E trusts F
subject to
conditions Y
F trusts b
subject to
conditions Z
a trusts D
D
F
E
Public-key
user a
[email protected]
a trusts this path to b, subject to the progressive
application of constraints X, Y and Z
17/07/2015
Crypto, PGP and PKI Overview
52 /
X.509 PKI Characteristics
•Versions 1 & 2
•Version 3
•
Certificate information
•
•
X.500 names only. Includes CA & subject names, subject public key, and a validity period.
Fully extensible, can include any information.
•
CA arrangement
•
•
No mandated CA arrangement, however the general hierarchy with cross-certificates is encouraged. No trust constraint mechanisms.
Trust constraint mechanisms are provided. The general hierarchy with cross-certification is still encouraged.
•
CA  Subject  User relationship
•
CAs, subject and users are distinct. (Both)
•
CA  Subject  User trust relationships
•
•
Each user is expected to fully trust at least one CA. CAs have no mechanism for manipulating their trust relationships with subjects and other CAs.
Each user is expected to fully trust at least one CA. CAs can constrain how their trust in subjects and other CAs is delegated.
•
Certificate validation method
•
•
Offline. Certificate chains are stored locally and / or transmitted with every message. Validation is performed by checking the validity period of each certificate
and verifying that the certificate does not appear on the latest available CRL.
Offline, but can be online through yet-to-be-defined extensions.
•
Certificate revocation method
•
•
Simple CRLs only.
Sophisticated CRL mechanisms. Online methods can be defined via extensions.
•
Identity vs. credential certificates
•
•
Identity certificates only. Credentials may be attached to the named X.500 directory entry.
Mainly identity certificates. Certain standard extensions provide some credential-like functionality. Can be extended to provide full credential certification.
•
Irrefutability and strong authentication
•
•
Authentication strength based on the accuracy of X.500 entries. CA is responsible for issuing certificates that are not misleading.
CA is still responsible for certificate accuracy, but use of non-X.500 names may make this more difficult.
•
In-band vs. out-of-band authentication
•
Users must obtain at least one CA key out-of-band. Also, the extensive use of OIDs requires out-of-band communication whenever a new extension is defined.
(Both)
•
Anonymity
•
•
Anonymous only to the degree that an X.500 entry can be anonymous.
Extensions can be used to provide fully anonymous service.
17/07/2015
Crypto, PGP and PKI Overview
53 /
Basic Characteristics of the PEM PKI - Privacy Enhanced Mail
•
Certificate information
•
PEM certificates are X.509v1 certificates.
•
CA arrangement
•
PEM uses a rigid, top-down CA hierarchy.
•
CA  Subject  User relationship
•
Users and subjects are distinct from CAs. No PEM user can be a CA.
•
CA  Subject  User trust relationships
•
All PEM users must place complete trust in the IPRA, as all certification paths start with the IPRA’s key. A user must also trust the PCAs and CAs they
encounter in a certification path. The user must be familiar with each PCA’s policies, and trust that the PCA and the CAs have not deviated from those policies.
•
Certificate validation method
•
Certificates are validated “online” using email. It is expected that the message originator would include the full certification path to his key in the message, which
the recipient can validate using the IPRA’s key. While performing this validation, the user must also verify that no certificates have been revoked or expired, and
that DN subordination has been followed.
•
Certificate revocation method
•
PEM uses X.509v1 CRLs, distributed via email to each user.
•
Identity vs. credential certificates
•
PEM certificates are purely X.509v1 identity certificates.
•
Irrefutability and strong authentication
•
The PEM architecture allows for strong authentication of users.
•
In-band vs. out-of-band authentication
•
Each user needs to obtain the IPRA’s key via some out-of-band means. Given that key, all other authentication can be performed in-band.
•
Anonymity
•
PEM provides an anonymity mechanism through what it calls “PERSONA” CAs. A PERSONA CA is distinct from a regular PEM CA in that it explicitly does not
vouch for the identity of its subjects.
17/07/2015
Crypto, PGP and PKI Overview
54 /
Internet Policy Registration Authority (IPRA)
•
The PEM CA hierarchy
IPRA
PCA
CA
CA
user
17/07/2015
CA
user
PCA
PCA
CA
user
CA
user
user
CA
user
user
Crypto, PGP and PKI Overview
55 /
The Secure DNS PKI Characteristics
•
Certificate information
DNS certificates can contain any kind of resource record.
•
CA arrangement
Each DNS CA corresponds to a DNS zone, so the CAs are arranged according to the domain name hierarchy. Any CA can certify the key of any other CA. This forms a general
hierarchy with cross-certificates.
•
CA  Subject  User relationship
The subject of a DNS certificate can be any entity that can be assigned a DNS name. Thus the CA of a subject is determined by which Internet domain the subject exists under.
When the subject does not have her own, distinct domain, she must have a close relationship with her CA. When the subject does have her own domain, she is her own
CA.
•
CA  Subject  User trust relationships
Each user is expected to fully trust at least one CA. The DNS’s hierarchical CA structure lets one know if an entity’s certification is derived from a particular CA (via the entity’s
DNS name). However, there is little a CA can do once it has certified a sub-zone – the sub-zone has full authority over its domain and the parent CA has no means of
constraining its trust. For example, a sub-zone can cross-certify an untrustworthy domain that its parent would not, yet users in the sub-zone might believe that they are
still following the policies of its parent.
•
Certificate validation method
DNS certificates are validated online. Their validity period is defined by both the TTL and certificate’s expiration date. If either indicates an expired certificate then the certificate
must be revalidated. The TTL mechanism is used to reduce the online bandwidth requirements of the DNS, however it does present a window of opportunity for a
revoked certificate to be falsely considered as valid.
•
Certificate revocation method
Certificates are revoked when an entity indicates to its CA that some of its information has changed (e.g. a user has changed their email key) and the CA updates the
appropriate entries in its server. The time it takes for the change to propagate throughout the system is at most the largest TTL of the changed entries.
•
Identity vs. credential certificates
The DNS certificate identifies the owner of a public key by assigning the key a DNS name. Credential certificates are not defined, although credential-serving systems can be
built atop the secure DNS.
•
Irrefutability and strong authentication
Strong authentication is provided as long as a DNS name resolution only passes through secure zones. The more such zones a resolution passes through, the less its result
can be trusted, so the secure DNS requires that if a shorter resolution path is found, then any longer ones should be discarded in its favor.
•
In-band vs. out-of-band authentication
Each resolving application needs to be initialized with at least one trusted key obtained via some out-of-band means. This key is usually the zone key of the domain in which the
resolver resides.
•
Anonymity
Anonymity was not a design goal of the secure DNS, although it does not make anonymity impossible to achieve.
17/07/2015
Crypto, PGP and PKI Overview
56 /
The DNS hierarchy
•
DNS or internet hierarchy, like PKI …
.
com.
edu.
3
2
foo.com.
1
5
bar.edu.
6
Alice
17/07/2015
4
7
Crypto, PGP and PKI Overview
Bob
57 /
Code Signing Digital IDs for Sun Java Signing
Realizing the Possibilities of Internet Software Distribution
•
Who Needs a Code Signing Digital ID?
Any software publisher planning to distribute code or content over the
Internet or through an extranet risks impersonation and tampering.
VeriSign Code Signing Digital IDs for Sun Java Signing protect against
these hazards.
•
VeriSign offers Code Signing Digital IDs designed for commercial
software developers: companies and other organizations that publish
software. This class of Digital ID provides assurance regarding an
organization's identity and legitimacy, much like a business license,
and is designed to represent the level of assurance provided today by
retail channels for software.
•
Content Source: End users can confirm that the software really
comes from the publisher who signed it.
Content Integrity: End users can verify that the software has not
been altered or corrupted since it was signed.
•
17/07/2015
Crypto, PGP and PKI Overview
58 /
Java Plug-in Security & certificate
The Java Plug-in Security
Warning dialog box launched by the WebStart launcher
The Certificate Properties
dialog box launched by the WebStart launcher
1..
Verifying the Code Signing
Digital ID
on the end user's computer.
17/07/2015
Crypto, PGP and PKI Overview
59 /
Kerberos architecture « all in one » - MIT & ECMA 1990
•
•
A unique repository and common authentication for users with GSS-API
MS200, Opengroup DCE & SAP R/3 « backbone »
Security
server
Administration:
Users
DB
A single users DB
Limitations:
GSS-API
interface
•Application development
•Client / server oriented
•Not for asynchrone applications (email)
•Symetric encryption => admin must check
All ditributed components envolved in the process
Developpers:
A single API security list
• Not ready for an open www architecture, more adapted inside enterprise for strong centralized
administration
Users:
A single authentication DB
Applications
17/07/2015
Crypto, PGP and PKI Overview
60 /
Standard components for e-Business driving PKI and LDAP
about source authentication and confidentiality
•
•
S/MIME for source authentication and email confidenciality
SSL -Secure Socker Layer-, now TLS - Transport Socket Layer:
for Web transactions
• WTLS – Wireless Transport Layer Security => radio transmission
All are public Keys based, using RSA and DSA algorithms
•
Public Keys based encryption is not sufficient and needs:
– A Security administration Infrastructure to declare users, applications or networks
components to allocate private and public keys on a secure way,
– A secure way and process to distibute public Keys
– A hight level of security protocol and secured interfaces to allow secure
communications between applications.
•
=> public Keys encryption with PKI , LDAP and secutity protocols like SSL
and S/MIME are the keys for internet security infrastructure.
17/07/2015
Crypto, PGP and PKI Overview
61 /
PKI, LDAP & public Keys encryption Architecture
Administration:
-Keys management
Public Key
Infrastructure
Administration:
Keeps certificates
And Public Keys
Public Keys
encryption
LDAP
server
Get Public Keys
Developpers
-users registrery
-Security information creation
-Keys and certificates management
Developpers
LDAP Interface
LDAP Interface
X509 interoperability ?
Applications
Applications
Users:
Secured transactions
17/07/2015
Crypto, PGP and PKI Overview
62 /
Doubt about certificates generation, questions of Trust
On March 22, 2001, Microsoft issued a security bulletin alerting the Internet community that twodigital certificates were issued
In Microsoft’sname by Verisign to an individual – imposter – used to validate virus as MS secured products
Hight security
But what’s about social engineering ?
Are CA really secure ?
Certification
Authority
Delivery
rules
2
Local Registration
Authority
3
SSL ? ?
•Keys
delivery
Secured environment
Complexity of PKI
Processes + implementation
CA1
1
Certificates
request
CA1
•Certificates
Drawing up
Security Policy
CA1
USER
SSL risk
Unsecured
Network, OS, IOS,
applications
17/07/2015
Unsecured partners
Unsecured
Network, OS, IOS,
applications
Crypto, PGP and PKI Overview
63 /
Problem: garbage in , garbage out
•
Breaking the Yellow Lock (SSL) – by Richard Formo Feb 13 2002
–
–
–
–
–
•
The myth of the Yellow Box:
–
–
–
•
PKI provides Web users with a false sense of security that undermines the security of their online information: fraudulent information in, fraudulent certificate out
Potential hidden vulnerabilities that software licences may create for users
See the securityFocus vulnerability description
PKI is the foundation technology that makes SSL possible, ostensibly secure
The problem is, they AREN’T secure. This is a fundamental problem with how PKI is deployed
by the industry
This indicates that the web-based internet link between browser and web server is encrypted to
prevent data sniffing. While PKI ensures that the initial transmission of information along the
internet is encrypted, in subsequent steps –behind the web server – the customer’s personal
information may be communicated in clear text so that anyone who acces to it can read it
Many commercial sites store this information in uncrypted databases and in clear text queues
waiting for credit card authorization to occure !
PKI as a sole solution is questionable at best. In addition to providing Internet encryted
information, including an active, third party authentication of certificates an preserving servers
to serve as more effective ‘defense in depth’ layer and help prevent man-in-the-middle
interception attacks and data sniffing.
Human are still the Weakest link – Good-bye!
–
In March 2001, virus writers had obtained illicit certificates that could potentially be used to
authentificate malicious code as legitimate MS software.The virus writers were able to hijack
the process by submitting fraudulent information on the application form. The notary has no
interest in the content of the documment, they simply confirm that the signature match the
government-issued identification presented to them. As it’s quite easy to obtain fraudulent
drivers licences …
17/07/2015
Crypto, PGP and PKI Overview
64 /
PKI projects implementation incoherences
•
•
The level of security in most of the common enterprise is week: budget contrainst
–
–
–
PKI represent a hight investment, project management may cost more that hard & software
–
–
–
–
–
–
–
–
•
So forget it for less that a few 1000 of users !
But you need to begin with a prototype of a few 100 users !
25 steps to successfull Implementation of a coorporate PKI to meet clearly defined business objectives.
PKI us much more than complex technology: costs, complexity of integration, underlying policies, organization …
Most implementations are still in pilot projects.
Gartner said that most organisation implement small pilot PKI project for between $80.000 and $100.000, with costs split equally between
software licences & professional services. But a full-scale rollout is likely to run more than $1m !
It’s not interesting only for email encryption because of the price, this should be implemented for most of applications,
But not all applications are X509v3 compliante !
Risks of PKI:
–
–
–
–
–
–
–
–
–
–
•
First solve that point inside !
But what about other enterprises and partners !
How to ensure and end to end user secure process ? With end user as weak point link to a complex process ?
Private keys are maintained by certificates authorities, which are trusted to maintain their privacy. If the certification authorities
themselves are insecure, the confidentiality of private keys they maintain is at risk.
Anyone who knows an individual’sprivate key could act as an imposter.
Contigency plan must be made for loss of private keys or disruption of service on PKI servers.
Many organization lack internal expertise.
Laws on digital signature vary by country. This is especially important for multinational enterprises.
Hidden rules: certificates do not make clear to the user the complete set of rules that gouvern their insurance, maintenance, use and
proposés
certaines
banques
revocation. The user is not aware of the inherent limitations exposedServices
and the
limitedpar
coverage
under
the law and under the CA’s disclaimer.
Underlying concept of trust ? Hard-trust is not transitive, not distributive and
symmetric
to
a
degree,
Loyds …. Bred ..
soft-trust is transitive, distributive and symmetric to a degree
A lot of risk to discover … just like Virus and encryption: anti-virus cannot scan an encrypted email
The wekest link of the security chain: users and the security of any CA system is based on many links and they’are not all cryptographic –
people are involved
The added benefit ist that you get SSO –Single Signe On – Unfortunately, the security value of authentication is completely defeated by SSO.
Authentication is supposed to prove that the user is present at the controlling computer at the time of the test. Under SSO, when the user
has to leave the room for any reason, any passing person can walk up to that user’s computer an sign on somewhere via SSO mechanism …
for all PKI-enabled applications
Offre aux entreprises
Security is very difficult, both to understand and to implement.
–
Busy system administrator and IT managers don’t have the time and the money to really get under the casing of security technologies.
PKI vendors know what busy people need: a minimum impact product – a one stop PKI shop. So that’s what vendors offer. Reallity still
falls far short of this promise, but then business and PKI vendors have something to sell.
17/07/2015
Crypto, PGP and PKI Overview
65 /