Skip to main content
shopping_basket Basket 0

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.


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

RDN	                Value
Common Name (CN)

Property	       Value
Issuer	               CN = Let's Encrypt Authority X3,O = Let's Encrypt,C = US
Subject	               CN =
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	     ,

Certificate Detailed Information
        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
            commonName                = Let's Encrypt Authority X3
            organizationName          = Let's Encrypt
            countryName               = US
            Not Before: Feb 12 08:31:55 2020 GMT
            Not After : May 12 08:31:55 2020 GMT
            commonName                =
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                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
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:
            Authority Information Access:
                OCSP - URI:
                CA Issuers - URI:
            X509v3 Subject Alternative Name:
            X509v3 Certificate Policies:
                ......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

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”, , © 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 analogue electronics for neuroscience labs (and his MD grade). Later: database engineering, C++, C#, industrial hard- and software developer (transport, automotive, automation). Designed and constructed the open-source PLC / IPC "Revolution Pi". Now offering advanced development and exceptional exhibits.

Recommended Articles

DesignSpark Electrical Logolinkedin