Securing an embedded system is incredibly important and having a digital signature plays a crucial role in that. A digital signature confirms that a specific piece of information came from a specific organization (i.e. the one with the private key as described below) and has not been modified.
Follow-up articles will firstly cover related issues such as how to secure and handle your private key, why this is so important, and how SEGGER does it. After that, articles will address how digital signatures are applied to solve particular problems, who stands to benefit, and what the costs are.
This article discusses the basic principles of how to secure your embedded system.
Public-key cryptography and the digital signature
The accepted method of authenticating data is to use public-key cryptography, also called asymmetric crypto, which uses an organization’s public (non-secret) key and a highly secured private key. The private key is used to generate a digital signature. Without access to that private key it is impossible to generate a signature that can verify data with the public key.
Whenever firmware is transferred, checked, or updated, a digital signature over the data is first checked to confirm that it was, in fact, generated using the private key. Positive confirmation means the firmware comes from the correct source and is unmodified.
The most critical part of the process is keeping the private key secure.
(For more info, see the links at the bottom.)
Hashing
Algorithms such as RSA (more below) encrypt data.
A hash function accepts an input of any size and returns a fixed-size output.
Hashing is a one-way function: For any given unique message M1, with a hash of H, it is practically impossible, and certainly infeasible (assuming a secure bit size – currently 256+), to construct a second message, M2, whose hash would also be H. A hash function that is secure enough to guarantee this uniqueness is said to be collision-proof. This means the hash of a document is considered to be as unique as the document itself.
By way of example, SHA-2 (Secure Hash Algorithm 2) is a widely used set of cryptographic hash functions, one of which is SHA-256 which we will use here. Generic hash generators, such as these online hash calculators at segger.com, accept any string and produce a number of hashes, generated by various algorithms, including SHA-256.
Here are two string inputs:
- Everyone should have a digital signature.
- Everyone should have a digital signature!
which are almost identical, and here are their SHA-256 outputs:
- 0f9c1621352b97f88f8458842134af9ec697d9e6316ec48e93fbb3b08624857a
- 4d96f61884e428cfc357eb4a437d2e537e2022208f4cd0907be40b8a02fbb148
which are wildly different.
So we use a hash because it is small and provides a secure way to confirm that a document has not been changed. Hashing makes the signing process more efficient.
With hashing and encryption, we have, for all intents and purposes, a system that will not be cracked by brute force. Given the current state and availability of computer resources, the universe will end before the code is cracked.
Try it yourself: How to sign, send, receive and verify a file
Here is the process for sending a file that can be tested to be authentic and testing that file once received. For embedded systems, the process is very similar while the basic principles and the underlying software are exactly the same.
To sign and send:
- The sender distributes the organization’s public key to the receiver in advance so that the receiver can be certain it is from the correct, trusted, source.
- Distribution is by some public key infrastructure (PKI) or by simple email attachment or download link, with the key ultimately stored on disk. When the receiver is a device that uses automation to authenticate firmware updates, the public key is programmed into the device’s non-volatile storage during production. As you might expect, SEGGER’s Embedded Experts streamline this production process with products such as the Flasher Secure.
- The sender uses the document plus a hash function to produce Hash#1.
- Hash#1, the private key, and the RSA cryptosystem are used to produce a Signature.
- The sender then sends the document and the signature.
To receive and verify:
- The receiver already has the public key.
- The receiver receives the document and the signature.
- The receiver uses RSA and the public key to decrypt the signature, i.e. to turn the signature back into a hash, which is Hash#2.
- The receiver compares Hash#1 and Hash#2
- If the hashes are identical the document is confirmed to have come from the correct source and to be unmodified.
SEGGER’s emSecure Sign & Verify application
It should come as no surprise that SEGGER has a way for you to check this out, free of charge.
Below is an example of exactly how to sign and verify a document, in this case using a MacBook Air with Apple’s M1 chip.
It is a simple drag-and-drop process using the free “emSecure Sign & Verify” utility from SEGGER. Click here to visit the Sign & Verify page , then click the box on the right, under Resources, for the list of downloads of free utilities from SEGGER. Find the appropriate download description (for the MacBook Air M1 2020 it is “SignAndVerify, based on emSecure (macOS 64-bit Apple M1)” near the bottom), click the download button on the right, accept the very short, ten-sentence, terms of use, and the download begins.
In your downloads folder you’ll soon see: “SEGGER_emSecure_SignAndVerify_macOS_V244_arm64.dmg”.
When you double-click this, you see “SignAndVerifyV2.44” which you then double-click to see these two important files:
The rest is even easier.
Double-click “emKeyGenRSA_LiteExe” and then “Open” to generate both the public key and the private key. They show up as “emSecure.prv” and “emSecure.pub” (on a MacBook, they are stored in your user download folder.)
Next you double-click “SignAndVerify.app” and then “Open” to use the emSecure app.
Into the app I dragged and dropped a file called “emSecure S&V test.pages”. It immediately flashed, saying, “Signature generated”, and saved a file called “emSecure S&V test.pages.Signature” into the same folder from which I had dragged the file. The application has now hashed the file and used RSA, plus the private key, to generate the digital signature.
To a different MacBook Air I sent the files:
- “emSecure S&V test”
- “emSecure S&V test.pages.Signature”
- “emSecure.pub”
and saved them all in the same folder, which I called “emSecure verify”.
As the receiver, I first opened this folder with the three files (the document, the signature and the public key). Then I opened the emSecure “SignAndVerify.app”. Lastly, I dragged the document from the folder with the three files into the app interface. The result was: “File verified.”
This confirms that the document received is unmodified and was sent by the holder of the private key, i.e from the sender expected.
To double-check the process, I opened “emSecure S&V test.pages” and added a single blank space at the end. I then dragged this modified document, with the exact same name, back into the app and got this:
The system works!
Conclusion
Security is of critical importance, especially in embedded systems.
Thankfully, we have a solution!
Next, we will look at private key security and storage.
For more information on cryptography and digital signatures, see:
Wikipedia: Public-key cryptography
Wikipedia: Digital signature
A note on key length and RSA vs ECC
RSA stands for the inventors Rivest–Shamir–Adleman and ECC stands for Elliptic Curve Cryptography. RSA is older and more established while ECC is more modern (for what that’s worth). They work in different ways but serve the exact same purpose (think diesel fuel versus gasoline).
ECC provides more security than RSA for equivalent key lengths. A key size of 1,024 bits is required for RSA versus 160 bits for ECC. However, for the same level of security, RSA verifies signatures much faster than ECC and so wins the boot-up challenge.
For embedded systems, boot-up speed can be very important, making RSA the better choice.
Both are considered uncrackable using the technology available today and for the foreseeable future.
(We may write a future blog article comparing RSA with ECC.)