In this blog, I would like to introduce some background concept on the ECDSA, ECDH and AES128 first. And then, on the next post, I will describe how to use such technology on the BLE connection at the Application layer. Particularly, for the internet of things is not just for personal device, it can’t work with bonding/pair with mobile. It can only do the encryption at the application layer. For example, the door lock is used to share with the whole family member.
ECDSA / ECDH
- ECDSA (Elliptic Curve Digital Signature Algorithm), an algorithm to create and verify signatures for any kind of data (for example, a firmware image)
- ECDH (Elliptic Curve Diffie-Hellmann), a key agreement protocol that allows to establish a shared secret over an insecure channel
I will cover the topic as below.
- Elliptic Curve Digital Signature Algorithm (ECDSA)
- Elliptic-curve Diffie–Hellman (ECDH)
- Symmetric Encryption on AES128
Elliptic Curve Digital Signature Algorithm
Some online Tutorial of ECDSA are below:
- The Fundamentals of an ECDSA Authentication System: ( https://www.maximintegrated.com/en/app-notes/index.mvp/id/5767 )
- ECDSA: The digital signature algorithm of a better internet ( https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ )
A few concepts related to ECDSA:
- private key: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, someone with the private key that corresponds to funds on the block chain can spend the funds. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).
- public key: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called x. The older uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called x and y (2 * 32 bytes). The prefix of a compressed key allows for the y value to be derived from the x value.
- signature: A number that proves that a signing operation took place. A signature is mathematically generated from a hash of something to be signed, plus a private key. The signature itself is two numbers known as r and s. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are either 73, 72, or 71 bytes long, with probabilities approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability.
Key Pair Generation
Before an ECDSA authenticator can function, it needs to know its private key. The public key is derived from the private key and the domain parameters. The key pair must reside in the authenticator’s memory. As the name implies, the private key is not accessible from the outside world. The public key, in contrast, must be openly read accessible. Figure 2illustrates the generation of the key pair.
A random number generator is started and, when its operation is completed, delivers the numeric value that becomes the private key d (a scalar). Next, the public key Q(x,y) is computed according to Equation 1 through point multiplication:
|Q(x, y) = d × G(x, y)|
Elliptic-curve Diffie–Hellman (ECDH) is an anonymous key agreement protocol that allows two parties, each having an elliptic-curve public–private key pair, to establish a shared secret over an insecure channel. This shared secret may be directly used as a key, or to derive another key. The key, or the derived key, can then be used to encrypt subsequent communications using a symmetric-key cipher. It is a variant of the Diffie–Hellman protocol using elliptic-curve cryptography.
ECDH is used for the purposes of key agreement. Suppose two people, Alice and Bob, wish to exchange a secret key with each other. Alice will generate a private key dA and a public key QA=dAG (where G is the generator for the curve). Similarly Bob has his private key dB and a public key QB=dBG. If Bob sends his public key to Alice then she can calculate dAQB=dAdBG. Similarly if Alice sends her public key to Bob, then he can calculate dbQA=dAdBG. The shared secret is the x co-ordinate of the calculated point dAdBG. Any eavesdropper would only know QA and QB, and would be unable to calculate the shared secret.
After calculate the shared secret, it can use as the baseline to do the data encryption. For example, someone would use such shared secret, plus IV (initial vector) + sequence number on the AES128 (symmetric encryption).
Symmetic Encryption AES 128
There are 6 difference mode of the AES128. (More details can be found at AES128 Wiki)
Mode 1: ECB (Electronic Codebook Book)
The simplest of the encryption modes is the Electronic Codebook (ECB) mode (named after conventional physical codebooks). The message is divided into blocks, and each block is encrypted separately.
The ECB is ready on the Nordic NRF5 Series MCU.
Mode 2: CBC (Cipher Block Chaining)
Ehrsam, Meyer, Smith and Tuchman invented the Cipher Block Chaining (CBC) mode of operation in 1976. In CBC mode, each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block depends on all plaintext blocks processed up to that point. To make each message unique, an initialization vector must be used in the first block.
Mode 3: CTR (Counter)
Like OFB, Counter mode turns a block cipher into a stream cipher. It generates the next keystream block by encrypting successive values of a “counter”. The counter can be any function which produces a sequence which is guaranteed not to repeat for a long time, although an actual increment-by-one counter is the simplest and most popular. The usage of a simple deterministic input function used to be controversial; critics argued that “deliberately exposing a cryptosystem to a known systematic input represents an unnecessary risk.” However, today CTR mode is widely accepted and any problems are considered a weakness of the underlying block cipher, which is expected to be secure regardless of systemic bias in its input. Along with CBC, CTR mode is one of two block cipher modes recommended by Niels Ferguson and Bruce Schneier.
Mode 4: Cipher Feedback (CFB)
The Cipher Feedback (CFB) mode, a close relative of CBC, makes a block cipher into a self-synchronizing stream cipher. Operation is very similar; in particular, CFB decryption is almost identical to CBC encryption performed in reverse:
Mode 5: Output Feedback (OFB)
The Output Feedback (OFB) mode makes a block cipher into a synchronous stream cipher. It generates keystream blocks, which are then XORed with the plaintext blocks to get the ciphertext. Just as with other stream ciphers, flipping a bit in the ciphertext produces a flipped bit in the plaintext at the same location. This property allows many error correcting codes to function normally even when applied before encryption.
Mode 6: Propagating Cipher Block Chaining (PCBC)
The Propagating Cipher Block Chaining or plaintext cipher-block chaining mode was designed to cause small changes in the ciphertext to propagate indefinitely when decrypting, as well as when encrypting. In PCBC mode, each block of plaintext is XORed with both the previous plaintext block and the previous ciphertext block before being encrypted. As with CBC mode, an initialization vector is used in the first block.
After reading this post, if you think it is useful, please give a “Like”. Your appreciation would give me more motivation for sharing excellent materials.