Rainer Perske
Westfälische Wilhelms-Universität
Zentrum für Informationsverarbeitung
Zertifizierungsstelle
Röntgenstraße 7-13
48149 Münster
ca@uni-muenster.de
+49 251 83 31590 (fon)
+49 251 83 31555 (fax)
ca. 90 min.
Rainer Perske
Westfälische Wilhelms-Universität
Zentrum für Informationsverarbeitung
Zertifizierungsstelle
Röntgenstraße 7-13
48149 Münster
ca@uni-muenster.de
+49 251 83 31590 (fon)
+49 251 83 31555 (fax)
No matter whether IP packet, e-mail, WWW page or any other kind of message:
The message does not arrive at the recipient
The message is read by a meddler during transfer
The message is altered by a meddler during transfer
A meddler sends a faked message
The sender wants:
(to make the message arrive at the recipient)
to prevent meddlers from reading or altering
The recipient wants:
to check or prove that the message is unaltered
to check or prove that the message originates from the indicated sender
Encryption
prevents meddlers from reading
complicates purposeful alterations by third parties
Electronic (digital) signature
proves that the message originates from the indicated sender
proves that the messages is unaltered
proves it to anybody
Cannot prevent message loss
Usually same key for encrypting and decrypting
Every combination of two participants needs a separate key
Both partners need to keep the key secret carefully
⇒ Signatures cannot be checked by third parties
The number of keys increases quadratically with the number of participants
Calculations are fast
Arbitrary numbers can be used as key (usually)
If the system itself has no weakness:
128 bit keys are considered quite secure (2128 possibilities)
Even much better: 160, 192, 224, or even 256 bit keys
Each bit more doubles the security
64 bit keys are insecure (simply try all possible keys)
Examples
Secret writings, DES, RC5, IDEA, CAST, Blowfish, Twofish, Rijndael (AES)
Uses two complementary keys (key pairs)
One key for encrypting, the other for decrypting
One key for signing, the other for verifying
From one key the other key cannot be calculated
⇒ One key can be public
Only one key pair per participant
One key (the private key) is used by the owner of the key pair
The other key (the public key) is used by all other participants
The number of keys increases only linearly with the number of participants
Use the private key for those actions that only the owner may do
Signing (by sender) and verifying (by any recipient or third party):
Only the sender may sign
⇒ private key of sender for signing
⇒ corresponding public key of sender for verifying
Encrypting (by any sender) and decrypting (by recipient):
Only the recipient may decrypt
⇒ private key of recipient for decrypting
⇒ corresponding public key of recipient for encrypting
Encrypting prevents meddlers from reading
Verifying the signature proves the originating sender
Verifying the signature proves that the message is unaltered
Everybody can verify the signature
Encrypting and signing are independent of each other
Need only signing? ⇒ only the sender needs a key pair
Need only encrypting? ⇒ only the recipient needs a key pair
Public keys can easily be distributed
New danger: How do we know that a public key is genuine?
Only numbers with certain properties can be used as keys
Systems are based on various mathematical issues
Huge prime numbers
Examples: RSA, ElGamal/DH, Rabin, ...
2048 bit keys are considered safe
512 bit keys are considered weak (can be factored)
Elliptic curves
170 Bit keys are considered safe
Other systems, some can only be used for signing: DSS, ...
Calculations are slower (by a factor of 1000) due to huge numbers
Too slow for huge amounts of data
Combine secret key system + public key system + fingerprints to speed up
Mathematical hash function, one-way function
Calculations are fast
Create from message of arbitrary length an essence (fingerprint) of fixed length
Essences are very short, 128 to 512 bit (16 to 64 byte)
Cryptographic requirement: From an essence the message cannot be calculated
More drastic requirement: No two different messages with the same essence can be found (birthday paradoxon)
Then signing the essence is as good as signing the message
Example: MD5 (128 Bit, weak), SHA-1 (160 Bit, no longer recommended), SHA-2 (256 to 512 Bit, safe), RIPEMD-160, ...
To sign:
Fast: Calculate essence of message
Slow but few data: Encrypt essence with sender's private key
Transmit message and signature to the recipient
To verify:
Slow but few data: Decrypt signature with sender's public key
Fast: Calculate essence of message
Fast and few data: Compare the results of both steps
(This signature method is used most often but there are other methods.)
Don't worry – your software makes all this for you
To encrypt:
Create random (!) key for secret key system
Fast: Encrypt the (signed) message with random secret key
Slow but few data: Encrypt the random secret key with recipient's public keys
(Do last step for every recipent)
Transmit encrypted message and encrypted random key to recipient
To decrypt:
Slow but few data: Decrypt the encrypted random secret key with the recipient's private key
Fast: Decrypt the (signed) message with the random key
Don't worry – your software makes all this for you
Names like TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA describe the algorithms combined
Sender
signs with sender's private (secret) key
encrypts with recipient's public key
Recipient
decrypts with recipient's private (secret) key
verifies with sender's public key
Always remember:
You need your private key only for signing and decrypting, never else
Danger: How do we know that a public key is genuine?
Often not feasible: Personal handover or trustworthy courier
Split the problem:
Transfer the public key (may be insecure)
Check the authenticity of the received key
How to transfer:
E-Mail, WWW, LDAP, Keyserver, etc.
e.g. DFN-PKI LDAP server: ldap.pca.dfn.de:389, Base-DN: O=DFN-Verein,C=DE
S/MIME signatures contain the public key, mail programs remember them
How to check the authenticity:
Check the fingerprint obtained from a trustworthy source
Check the signature of the message containing the key
(If sender = owner: The cat catches its tail?)
Check the certificate containing the key
Certificates are electronically signed confirmations
“This public key belongs to this identity (person, server)”
Fixed formats (OpenPGP, X.509, OpenSSH, ...) for automatic verification
Certificates contain:
Public Key (X.509) or its fingerprint (OpenPGP)
Owner of key (“subject”: full name or FQDN, organization etc.)
X.509: “CN=Rainer Perske, OU=Zentrum fuer Informationsverarbeitung, O=Universitaet Muenster, C=DE”
X.509: “CN=www.uni-muenster.de, O=Universitaet Muenster, C=DE”
OpenPGP: “Rainer Perske (office) <rainer.perske@uni-muenster.de>”
Further data (issuer, serial number, validity period, purpose, alternative names, e.g. e-mail addresses)
Signature created by issuer
Certificates do not contain the owner's private key!
Non-technical:
Is the issuer trustworthy?
Is the issuer competent?
This assessment is done by the person to whom the certificate is presented
Technical:
Verify the authenticity of the certificate
Either compare with a fingerprint obtained from a trustworthy source
Or check its signature with the issuer's public key
(The cat catches its tail? No, it catches the tail of the previous cat)
A certificate may be signed with a public key
which is contained in another certificate
which is signed with a public key
which is contained in yet another certificate
and so on ...
The final certificate is signed with itself: root certificate
Software vendors include many pre-checked root certificates, see below
A certificate is valid, if
the root certificate is genuine and
all issuers in the chain are trustworthy and competent
Our old chain: Deutsche Telekom Root CA 2 → DFN-PCA → WWUCA → server/user
Our new chain: T-TeleSec GlobalRoot Class 2 → DFN-PCA → DFN Global Issuing CA → server/user
Demo: Check certificate of this page
Demo: Edit trust of CAs in Firefox
A certification authority (CA) is somebody issuing certificates as his business
With OpenSSL: www.openssl.org
Set up a complete root CA:
mkdir demoCA demoCA/newcerts
touch demoCA/index.txt
echo 01 >demoCA/serial
openssl req -x509 -newkey rsa:2048 -out CA.crt -keyout CA.key
openssl x509 -in CA.crt -noout -text
By client: create a key pair and a request:
openssl req -new -nodes -out XY.req -keyout XY.key
By CA: create certificate:
openssl ca -days 10 -keyfile CA.key -cert CA.crt -in XY.req -out
XY.crt
openssl x509 -in XY.crt -noout -text
CAs and Root CAs are not “per se” trustworthy
Set up a policy with rules for security, target audience, privacy, methods, archiving, contents, life times, revocations etc. you declare to obey strictly
Announce yourself to the browser makers (for Mozilla use Bugzilla)
Example: Deutsche Telekom Root CA 2: https://bugzilla.mozilla.org/show_bug.cgi?id=378882
Request sent: April 2007; integration in Firefox+Thunderbird: July 2009
Rigorous checking of requirements (policies, audits etc.) over months and years
Requesting CA has to adapt every little bit of its policy and its operation to the requirements
Leading party in the ongoing development is the CA/Browser Forum: https://cabforum.org/
Most of our policy changes in the last years came due to new CA/Browser Forum requirements
It costs millions of Euros to operate a CA that meets all requirements:
All universities delegate CA operation to DFN and DFN cooperates with German Telekom
We don't want to trust “Honest Achmed”: https://bugzilla.mozilla.org/show_bug.cgi?id=647959
Serious background: blunders of Commodo, DigiNotaar and others
3 staff members (at ZIV) + 11 further team members (spread over WWU and UKM)
I spend some 10 % of my time for the WWUCA, all others far less.
X.509 certificates issued by the WWUCA (all in the DFN-PKI “Global” hierarchy):
| year | total | server | user | group | code | intern | (revoc's) |
|---|---|---|---|---|---|---|---|
| 2016 | 611 | 241 | 345 | 11 | 5 | 9 | (147) |
| 2015 | 323 | 176 | 135 | 3 | 2 | 7 | (73) |
| 2014 | 596 | 351 | 226 | 9 | 4 | 6 | (133) |
| 2013 | 369 | 177 | 180 | 4 | 3 | 5 | (45) |
| 2012 | 282 | 113 | 157 | 1 | 3 | 8 | (92) |
| 2011 | 309 | 81 | 217 | 3 | 1 | 7 | (36) |
| 2010 | 202 | 100 | 91 | 0 | 9 | 2 | (14) |
| 2009 | 158 | 69 | 86 | 0 | 0 | 3 | (20) |
| 2008 | 265 | 166 | 96 | 1 | 0 | 2 | (92) |
| 2007 | 307 | 159 | 136 | 1 | 2 | 9 | (18) |
2014: Heartbleed (OpenSSL bug), SHA-1 deprecation, Poodle (SSLv3 bug)
OpenPGP discontinued after 2011: Less than 15 requests per year
Service of the German Research Network provided by DFN CERT GmbH in
Hamburg
(CERT = Computer Emergency Response Team)
DFN-PKI team (8 members) operates and develops the DFN-PKI
5 X.509 hierarchies with different policies (“Classic”, “Global”, “Basic”, “Grid”, “SLCS”)
398 outsourced subordinate CAs of DFN e.V. members (incl. WWUCA)
OpenPGP discontinued due to lack of demand
No additional costs: DFN PKI service is part of the DFN Internet service
WWU + UKM + KA + FH + MPI together pay 250.000 €/a for 2×5 GBit/s cluster connectivity
DFN-PKI “Global” (sub-CA of “Deutsche Telekom
Root CA 2” resp. “T-TeleSec GlobalRoot Class 2”)
highest available security, approved by all market leaders
WWUCA is working in this hierarchy.
DFN-PKI “Classic” (root CA)
same security, but not approved by market leaders
was replaced by “Global” as soon as available
(2007)
DFN-PKI “Basic” (root CA)
relaxed requirements for identity control
not supported by WWUCA (all identification methods available to the
WWUCA that fulfil the “Basic” requirements also fulfil the
“Global” requirements.)
DFN-PKI “Grid” (root CA, for scientific grid
computing, acknowledged by the EUGridPMA)
has no subordinate CAs but I am registrar (currently no
demand)
DFN-PKI “SLCS“ (root CA, Short-Lived Credential
Service)
not supported by WWUCA due to lack of demand
OpenPGP (not a hierarchy but a web of trust)
discontinued by DFN after 2009 due to lack of demand
WWUCA continued service until 2011
Demo: Request certificate on ca.wwu.de
You:
generate a key pair (on that page)
pass the public key and personal data to the CA (on that page)
hand the key's fingerprint to the CA (face-to-face, presenting your identity card)
The CA:
Checks your identity
Checks the key's fingerprint
Creates the certificate using its private key
Sends the certificate to you (and publishes it if requested)
You:
join certificate and private key (do you know where it is?)
create a certificate backup file (.p12 or .pfx) that can be imported into any certificate-aware software
The WWUCA team member:
strictly obeys Certificate Policy (CP) and Certification Practice Statement (CPS)
Rules for security, target audience, privacy, methods, archiving, contents, life times, revocations etc.
checks all aspects of your request (perhaps applies corrections or rejects)
adds some data (Subject Alternative Names): e-mail addresses, login name, ...
compares the fingerprint on the form with that of the public key
thus the WWUCA knows the public key with the given fingerprint is yours
(electronically) signs a confirmation message to the certification server
(manually) signs and archives your request form
The well-protected DFN PKI certification server automatically:
checks the signature of the message and the accreditation of the signer
checks conformance of the request (only our domains? etc.)
So I cannot issue certificates for google.com
creates the certificate
mails the certificate to the requester
publishes the certificate via LDAP (if requested)
Use the LDAP server in Thunderbird:
Preferences | Composition | Addressing | Directory Server | Edit Directories... | Add
General: Hostname: ldap.pca.dfn.de; Port number: 389; Base DN: O=DFN-Verein,C=DE
Advanced: Search filter: (objectclass=*)
Several restrictions by CP+CPS (most of them technically enforced by DFN PKI):
Only servers and e-mail addresses belonging to WWU, UKM, or KA
emailAddress=. . . (only for users, at most one,
but see below)
CN=. . . (exactly one must be given; only name parts from
identity card, no “Prof.“ or alike)
OU=. . . (avoid
abbreviations)
O=Universitaet Muenster (or) O=Universitaetsklinikum Muenster
(or) O=Kunstakademie Muenster (must be given)
L=Muenster, ST=Nordrhein-Westfalen, C=DE (must be given)
Limited field length (64), limited character set for CN/OU/O/L/ST/C
a-z A-Z 0-9 ' ( ) + , - . / : = ? space
Convert german letters: ä ö ü ß Ä Ö Ü ⇒ ae oe ue ss Ae Oe Ue
Remove accents: Ibáñez ⇒ Ibanez, Łódź ⇒ Lodz
Phonetically transcribe other scripts: Δήμητρα ⇒ Dimitra, Ærøskøbing ⇒ Aeroeskoebing
Order matters and no other fields allowed
Multiple e-mail addresses (for users), host names (for servers) etc. can be given as Subject Alternative Names
Full qualified domain names (FQDNs) only (“www.wwu.de” but not “www”)
These names are verified, too
Hosts and domains are case-insensitive
Local parts of e-mail addresses are case-sensitive:
perske@wwu.de = perske@WWU.DE ≠ Perske@WWU.DE
Always use lowercase only, both in certificates and in your e-mail configuration
You present your certificate (and all intermediate certificates):
As a person/group: when sending a signed e-mail (attached to the signature)
The recipient will check signature and certificate
As a server: when accepting an TLS (HTTPS, IMAPS, POP3S, ...) connection
The client will check the certificate and compare the host name
As a client: when connecting to an TLS (HTTPS, IMAPS, POP3S, ...) server
Only if expected by the server (better security than password authentification)
The server will check the certificate
Try: https://xsso.uni-muenster.de/MeinZIV/
As a programmer: when signing a piece of software code
The operating system of the target system will check signature and certificate before installing
Bring the printed and signed „Zertifikatantrag für ein Nutzerzertifikat“
Bring your valid identity card or passport
Driving licence, student card, or other documents are not accepted!
Expired documents are not accepted!
Only accepted German documents: Personalausweis, Reisepass, Aufenthaltstitel
Rainer Perske
Westfälische Wilhelms-Universität
Zentrum für Informationsverarbeitung
Zertifizierungsstelle
Röntgenstraße 7-13
48149 Münster
ca@uni-muenster.de
+49 251 83 31590 (fon)
+49 251 83 31555 (fax)
© 2011-2017 Rainer Perske und Universität Münster