Industrial Security Part 4: About Digital Certificates, CAs and Elliptic Curves
In parts 1 to 3, I explained some basic cryptographic concepts, like encryption, decryption, symmetric and asymmetric keys and hashes. This fourth part builds on these concepts. So if you are not firm with them, please read parts 1, 2 and 3 before you proceed reading part 4.
Trusting the source of a public key
When I’ve explained the concept of asymmetric keys, I always said: “Pete can be sure that Helen has…”. But wait! Can he really be sure? What if it was not Helen who sent the aKpub but Susan? Then Susan would possess the corresponding aKpriv and not Helen. Susan would be Queen of communication and could fake whatever she wants. This kind of attack is called “man in the middle” (in our case maybe we should call it “woman in the middle”). When Helen and Pete are using public transmission lines like the internet, it is not difficult for Susan to exchange the public key on its way from Helen to Pete. The fantastic concept of public key exchange relies on confidence into the source of the key. It is all a question of trust. Can you trust the source to be who she claims she is? This is where a public key infrastructure (PKI) can help.
Public Key Infrastructure (PKI)
Pete could travel to Helen and get his key directly from here. But then we would no longer use public keys (PK) because it would be a private key between Helen and Pete. The concept of PK is that Helen uses the public key with all her communication partners. And Pete is not only communicating with Helen but maybe even sometimes with Susan. Then he would need a public key from Susan. At the end of the day, he would need to travel around the world to collect all the PKs he needs for his communication. So we need a much better structure of distributing public keys more securely. This is what a PKI is supposed to do.
Certificate Authority (CA)
Imagine there would be some kind of authority, let’s call him Sir Barcley. Pete could get Sir Barcley ‘s PK (maybe only valid for a specified limited time) by a secure way. Helen would send her public key to Sir Barcley, together with a signature containing her PK, her name and other data which does identify her. Sir Barcley would check her identity. He possibly even visits her to prove that she indeed generated the PK she gives him, that her name is Helen, that her hair is brown and that she lives at Legoland. All this data is in the Signature Helen gave Sir Barcley together with the PK which is needed to decrypt this signature. After having done all the checking, Sir Barcley is issuing a
This is an electronic document (a text file) which contains Helen’s identity data and her PK. It also includes a signature calculated over these items and signed with the private key of Sir Barkley. When Helen communicates with her friends, she sends this certificate instead of just the PK. Any receiver, including Pete, can proof this certificate to be indeed issued by Sir Barcley by using the PK of Sir Barkley (which they have got via a secure and trustful way). If Sir Barcley issues the certificate, they can rely on the PK included in this certificate to be issued by the subject named in the certificate. There is a standard of PK certificates, which is called X.509 and which describes the content and format of a PK certificate.
TLS and SSL
The concept of trusting a few CAs who issue many certificates is the basic principle of secure internet protocols. If you open a webpage using the secure Http protocol (https), your browser asks for a certificate and checks it with the PK of the CA. Browsers which can handle https regularly have a builtin list of PKs from well known CAs. The whole proof of identity by certificates including the use of PKs is standardised in the TLS (Transport Layer Security) protocol which formally was called SSL (secure socket layer). When you are visiting a secure web site, your browser should show a lock in front of the URL. Clicking on the lock will show you the certificate which was used to check the PK.
Here is an example of the certificate your browser gets when it calls https://revpimod.org:
Subject RDN Value Common Name (CN) revpimodio.org Properties Property Value Issuer CN = Let's Encrypt Authority X3,O = Let's Encrypt,C = US Subject CN = revpimodio.org Valid From 12 Feb 2020, 8:31 a.m. Valid To 12 May 2020, 8:31 a.m. Serial Number 03:59:04:8D:63:88:92:84:1B:AA:4D:A7:2A:0F:90:C2:F0:3C (291628039495863381646042141009153049686076) CA Cert No Key Size 2048 bits Fingerprint (SHA-1) 15:FE:BC:3F:63:B3:BB:9C:17:97:F7:31:2C:EC:4A:77:2B:CF:EC:4A Fingerprint (MD5) 21:30:F3:99:2E:53:6E:D2:ED:61:6D:E7:11:9E:B3:69 SANS revpimodio.org, www.revpimodio.org Certificate Detailed Information Certificate: Data: Version: 3 (0x2) Serial Number: 03:59:04:8d:63:88:92:84:1b:aa:4d:a7:2a:0f:90:c2:f0:3c Signature Algorithm: sha256WithRSAEncryption Issuer: commonName = Let's Encrypt Authority X3 organizationName = Let's Encrypt countryName = US Validity Not Before: Feb 12 08:31:55 2020 GMT Not After : May 12 08:31:55 2020 GMT Subject: commonName = revpimodio.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:cb:35:05:26:79:12:38:62:44:8c:48:7d:7f:65: d4:4f:e9:4c:67:9e:dd:75:8d:45:65:01:6b:a6:04: fd:fa:c4:61:ca:a1:24:2d:84:c7:b0:1e:05:a8:8c: a9:24:0c:2b:7d:87:c6:e9:55:30:fd:86:e4:9b:de: 1f:fe:45:ca:df:75:ab:be:78:33:59:52:37:b6:5d: 8e:9d:94:1c:17:52:26:49:0e:b5:2f:7f:87:fb:35: 8e:55:01:e5:1b:8f:1b:70:bb:a3:69:b3:82:b7:8e: 80:b1:09:87:11:fe:99:cb:8b:d7:24:ae:e3:35:db: 76:a5:b3:f4:d7:ef:94:98:f1:ab:d4:a3:92:dd:43: 63:9a:9a:2f:47:c3:92:9b:e7:87:6f:ea:17:34:a7: e7:1a:9b:57:8d:d8:4f:9b:a6:d6:e4:bb:b0:63:a6: 79:5d:a1:fe:91:23:49:68:d5:a6:1a:96:a6:b6:30: c4:c6:9e:32:42:0e:db:2b:0a:3b:52:7c:a9:8c:c2: ae:dd:b6:4c:b9:5d:d6:73:2c:87:ca:03:d1:25:76: 24:f4:8f:c3:96:92:ae:dc:c6:4b:d3:ad:92:dd:28: e1:15:7b:f7:86:96:df:fd:10:6c:10:e3:ff:35:ca: 80:56:30:99:06:30:ab:79:16:20:22:88:1c:55:71: 71:a3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: 37:D0:BA:99:F9:91:2E:6C:0C:1A:51:28:47:10:B9:68:BA:C0:C0:1F X509v3 Authority Key Identifier: keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1 Authority Information Access: OCSP - URI:http://ocsp.int-x3.letsencrypt.org CA Issuers - URI:http://cert.int-x3.letsencrypt.org/ X509v3 Subject Alternative Name: DNS:revpimodio.org, DNS:www.revpimodio.org X509v3 Certificate Policies: Policy: 188.8.131.52.2.1 Policy: 184.108.40.206.4.1.449220.127.116.11 CPS: http://cps.letsencrypt.org 18.104.22.168.4.1.1122.214.171.124: ......v......... N.f.+..% gk..p..IS-...^...p8..7.....G0E. ]2..`.....y..e.6.M.}.....P.......!..j=t.B+............Tw?.[..n....v.u.oSv.1.1.....Q..w.......).....7.....p8........F0D. 3.UHb...m..&.=.%....?E...z.a.vi5. ..r.3..r.?..9....J.R..........C. Signature Algorithm: sha256WithRSAEncryption 8f:2b:58:1d:de:da:0a:02:da:bd:cc:f1:de:15:e1:bf:1a:15: 28:d6:6f:5c:30:bb:04:f2:0b:f9:d9:53:e4:92:bf:52:e2:0f: ba:90:27:9c:ea:74:52:fa:62:c7:14:44:14:85:c7:31:1a:21: d0:6c:00:8b:70:0b:a4:7f:69:29:f9:73:5d:5d:a0:7a:c9:ef: ea:6f:b5:0e:70:e9:4d:1f:f5:03:0d:a1:86:aa:c0:b9:e3:a7: 4d:c2:5d:0f:c7:0e:ad:35:25:81:c4:5e:17:1f:e0:2a:ec:c9: 30:96:26:91:95:d1:5f:3d:f3:d5:43:2c:cf:4a:6f:3c:7f:73: ba:8c:d3:0f:22:b8:c6:49:6f:89:a9:64:7e:db:7c:ce:78:b3: 07:55:1b:04:c1:47:f3:61:57:f0:96:84:92:d4:ce:86:8f:0b: bb:72:c7:1c:38:df:34:2d:ad:ae:09:1d:b1:f6:4f:40:32:28: d5:49:cb:30:74:e9:d3:5a:2b:96:c7:a6:2b:70:6e:86:f9:8d: f3:db:62:3e:41:9a:12:68:da:f6:17:e5:0f:75:1d:e4:c0:ba: b3:0c:cb:37:0d:4a:a3:98:44:40:88:28:88:80:ac:0f:5a:6b: bf:03:f9:a6:21:cc:5f:16:c9:a0:2d:35:eb:a0:6f:20:30:ca: c2:f5:bc:92 -----BEGIN CERTIFICATE----- MIIFZzCCBE+gAwIBAgISA1kEjWOIkoQbqk2nKg+QwvA8MA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDAyMTIwODMxNTVaFw0y MDA1MTIwODMxNTVaMBkxFzAVBgNVBAMTDnJldnBpbW9kaW8ub3JnMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyzUFJnkSOGJEjEh9f2XUT+lMZ57ddY1F ZQFrpgT9+sRhyqEkLYTHsB4FqIypJAwrfYfG6VUw/Ybkm94f/kXK33WrvngzWVI3 tl2OnZQcF1ImSQ61L3+H+zWOVQHlG48bcLujabOCt46AsQmHEf6Zy4vXJK7jNdt2 pbP01++UmPGr1KOS3UNjmpovR8OSm+eHb+oXNKfnGptXjdhPm6bW5LuwY6Z5XaH+ kSNJaNWmGpamtjDExp4yQg7bKwo7UnypjMKu3bZMuV3WcyyHygPRJXYk9I/DlpKu 3MZL062S3SjhFXv3hpbf/RBsEOP/NcqAVjCZBjCreRYgIogcVXFxowIDAQABo4IC djCCAnIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQ30LqZ+ZEubAwaUShHELlousDA HzAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEFBQcBAQRj MGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlwdC5v cmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlwdC5v cmcvMC0GA1UdEQQmMCSCDnJldnBpbW9kaW8ub3JnghJ3d3cucmV2cGltb2Rpby5v cmcwTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEF BQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEDBgorBgEEAdZ5AgQC BIH0BIHxAO8AdgCyHgXMi6LNiiBOh2b5K7mKJSBna9r6cOeySVMt74uQXgAAAXA4 vZ43AAAEAwBHMEUCIF0ywddgjquAich5uPpl8jYGTQh9Ewu9qrZQ/v7JweO6AiEA vmo9dKJCKx/i3fe7Fn+alueSEVR3PwRbxhhup8LfFHYAdQBvU3asMfAxGdiZAKRR Ff93FRwR2QLBACkGjbIImjfZEwAAAXA4vZ+1AAAEAwBGMEQCIDPJVUhi5fa1bcS6 JrE9oyXB2tQSP0Wys9x6EmEVdmk1AiADnXKVM+0Rcho/37Q5kNOXlEodUucIwYD2 Lhru16JDwjANBgkqhkiG9w0BAQsFAAOCAQEAjytYHd7aCgLavczx3hXhvxoVKNZv XDC7BPIL+dlT5JK/UuIPupAnnOp0UvpixxREFIXHMRoh0GwAi3ALpH9pKflzXV2g esnv6m+1DnDpTR/1Aw2hhqrAueOnTcJdD8cOrTUlgcReFx/gKuzJMJYmkZXRXz3z 1UMsz0pvPH9zuozTDyK4xklvialkftt8znizB1UbBMFH82FX8JaEktTOho8Lu3LH HDjfNC2trgkdsfZPQDIo1UnLMHTp01orlsemK3BuhvmN89tiPkGaEmja9hflD3Ud 5MC6swzLNw1Ko5hEQIgoiICsD1prvwP5piHMXxbJoC0166BvIDDKwvW8kg== -----END CERTIFICATE-----
Different browsers use different formats to display the certificate. But you always see items like the public key of the certificate’s owner (sometimes as modulus and exponent), his URL, the algorithm used to generate the PK (normally RSA), the start- and end date of validity, the SHA256 hash value of the certificate (“fingerprint”), the issuer of the certificate, the ID of this certificate (given by the issuer to identify this certificate).
You will also detect that there are often “nested” certificates of several CAs. Some browsers (like Chrome) display them as a tree of certificates (leftmost tab:
Let me explain this by comparing it to a pyramid of trust. The browser knows the PK of the top CA (“root-CA”), which issues the “root certificate” for itself (such a certificate is known as “self-certificate” and is only trustworthy if you have a secure way to get the PK). The private key of this root CA a highly protected secret. If it ever gets known, all the derived sub-certificates are no longer secure.
The intermediate CAs needs to get their certificates from the root-CA. They put their data and their PK into their certificates and hand them to the root-CA to sign it (using the root-CA’s PK).
This “trust-chain” can go on over several levels until it ends at the end-entity certificate. The owners put their data and their PK into their certificates. An intermediate CA takes such a certificate and signs it with it’s PK.
When your browser reads such an owner’s certificate, it needs to get back to the “trust anchor”, which is the root certificate. It takes the issuer from the owner’s certificate A and looks into the issuer’s certificate V to find the PK to verify the signature of certificate A. If that is okay it reads the issuer from certificate V and looks into this issuer’s certificate Y. It takes the PK out of Y and verifies certificate V. This goes up the pyramid until the root certificate is reached (where the subject is identical with the issuer. The browser verifies this root certificate by using his built-in PK list. Only if the whole chain of signatures could be verified, the browser will use the PK of the bottom certificate to communicate with the server.
Once the browser has verified the server to be authentic and got his PK to communicate with the server, it does generate a symmetric unique session key (only valid for this browser session). It sends it encrypted with the PK to the server. Only the server can decrypt this key and uses it for symmetrical en- and decryption of further communication during this session. This is called Hybrid cryptosystem, and it uses the advantage of much less computing power involved with symmetric keys.
I have simplified the processes of TLS a lot. My aim was not to enable you to write TLS software but to let you understand the basics of cryptography.
I want to close part 4 by introducing the
Elliptic Curve Cryptography (ECC)
In part 2 of this series, I have explained the basic RSA algorithm using the modulus arithmetic and an exponential function to get a one-way algorithm for asymmetric cryptography. A newer type of one-way algorithm is called ECC, and it has several advantages over the classical algorithms. As I do not understand the maths behind it in full depth, I suggest you take the ECC algorithm as a black box like I do. All we need to know is that it works smoothly and much faster because you get the same level of security with much shorter keys. You need just 160-bit keys to achieve the security level of a 1024 bit RCA key. The computing power to reach a 256 bit RSA security level is about 64 times smaller when using ECC algorithms. That’s a reason why it is ideal for small systems with limited resources like smart cards, etc.
Due to the way ECC works, it always needs a random parameter called “ephemeral key” because it is used as a one-time-used-key and must be secret. Therefore systems using ECC (should) always have some kind of RNG on board (TRNG would be best practice).
While DSA signatures come with a single encrypted hash of the message, their ECC pendant (ECDSA) takes the hash, an ephemeral key and the private key to calculate two encoded parts: r and s. The verification algorithm uses the hash it has derived from the original message, the public key and the signature with r and s to calculate the result. This result tells you if the hash used for calculating r and s is identical with the hash you have used in the verification algorithm. Please keep these two values r and s which make the ECDSA signature in mind as we will find them again later when I demonstrate you a fantastic little crypto chip:
Taken with permission from “DeepCover Secure Authenticator with 1-Wire ECDSA and 1Kb User EEPROM”, https://datasheets.maximintegrated.com/en/ds/DS28E38.pdf , © 2017 Maxim Integrated Products, Inc., All Rights Reserved.
All significant security procedures like DSA ("Digital Signature Algorithm"), TLS ("Transport Layer Security", a protocol used in secure internet communication) and RSA (asymmetric key system) do exist in an ECC variant. The communication partners need to agree on which standard they use before they start the corresponding procedures.
We are finally at the point where we can use this knowledge in embedded hard- and software engineering. You will find applications in part 5 and 6.