DesignSpark Electrical Logolinkedin
Menu Search
Ask a Question

21 May 2020, 8:12

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

Certificate

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: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org
            1.3.6.1.4.1.11129.2.4.2:
                ......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.

Hybrid cryptosystem

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.

Volker de Haas started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and precise analogue electronics for neuroscience labs (and his MD grade). Later database engineering, C++, C#, hard- and software developer for industry (transport, automotive, automation). Ended up designing and constructing the open source PLC / IPC "Revolution Pi". Today engaged in advanced development as a service.

21 May 2020, 8:12