Rainer Perske
ca. 90 Min.
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:
Key sizes: 64 bit = broken; 80 bit = weak; 112 bit = still secure; 128 bit = secure
Even better: 160, 192, 224, or even 256 bit keys
Each bit more doubles the security: 2129 = 2 × 2128
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, mostly on:
Huge prime numbers
Examples: RSA, ElGamal/DH, Rabin, ...
Elliptic curves (ECC)
Examples: NIST Curve P-192 ... P-521, Curve25519, Curve448, E-521, Brainpool P256t1, ...
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
| Secret key AES etc. | Public key RSA |
Public key ECC | Keys are currently considered |
|---|---|---|---|
| 64 | 768 | 130 | broken |
| 80 | 1024 | 160 | weak |
| 112 | 2048 | 224 | (still) secure |
| 128 | 3072 | 256 | secure |
| 192 | 7680 | 384 | military secure |
| 256 | 15360 | 512 | long-time secure |
Larger keys are usually more secure
Very different absolute numbers depending on algorithm for same estimated security → table
But: Quantum computers will be able to break:
all currently used public key systems
some currently used secret key systems
Regarding security, key size is only one factor (usually far from being the weakest link in the chain)
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
Examples: MD5 (128 Bit, broken), SHA-1 (160 Bit, broken), RIPEMD-160 (160 Bit), SHA-2 (256 to 512 Bit), BLAKE2 (224 to 512 Bit), SHA-3 (Keccak, 224 to 512 Bit), ...
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.
S/MIME signatures contain the public key, most 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, O=Westfaelische Wilhelms-Universitaet Muenster, L=Muenster, ST=Nordrhein-Westfalen, C=DE”
X.509: “CN=www.uni-muenster.de, O=.....” (see above)
OpenPGP: “Rainer Perske (office) <rainer.perske@uni-muenster.de>”
Further data (issuer, serial number, validity period, purpose, alternative names like e-mail)
Signature created by issuer
Certificates do not contain the owner's private key!
You present your certificate:
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
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
... ... ...
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
When you present your certificate, you have to present the intermediate certificates, too
Then the certificate checker only needs the root certificate
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
The CAs in the DFN-PKI share a common “DFN Global Issuing CA” certificate
Demo: Check certificate of this page
Demo: Edit trust of CAs in Firefox
Contains all published certificates of all CAs in the DFN-PKI “Global” hierarchy
Use as external address book in e-mail programs:
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=*)
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
| year | total | server | user | group | code | intern | revoc's |
|---|---|---|---|---|---|---|---|
| 2018 | 895 | 396 | 464 | 21 | 5 | 9 | (198) |
| 2017 | 940 | 320 | 577 | 34 | 3 | 6 | (162) |
| 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) |
Sub-CA (not a root CA)
3 staff members (at ZIV)
further team members: 9 in WWU, 3 in 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) → table (updated 2019)
Peak in 2014: Heartbleed (OpenSSL bug), SHA-1 deprecation, Poodle (SSLv3 bug)
Current grow: WWU employees are obliged to protect their e-mail communication
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
4 X.509 hierarchies with different policies (“Global”, “Basic”, “Grid”, “SLCS”)
399 outsourced subordinate CAs of DFN e.V. members (incl. WWUCA)
OpenPGP discontinued after 2009 due to lack of demand
No additional costs: DFN PKI service is part of the DFNInternet service
WWU + UKM + KA + FH + MPI together pay 250.000 €/a for 2×15 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 “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, by WWUCA after 2011 due to lack of demand
Demo: Request certificate in user portal MeinZIV
You:
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? in your browser profile or in MeinZIV)
create a certificate backup file (.p12/.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)
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=. . . (optional; avoid abbreviations)
O=Westfaelische Wilhelms-Universitaet Muenster (or) O=Universitaetsklinikum Muenster
(or) O=Kunstakademie Muenster - Hochschule fuer bildende Kuenste (must be given)
L=Muenster, ST=Nordrhein-Westfalen, C=DE (must be given)
Limited field length (64), limited character set (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
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)
https://www.uni-muenster.de/WWUCA/