Isn’t Elliptical Curve Cryptography (ECC) overkill for a small embedded IoT device? This is a question we hear from time to time, but based on its computation requirements and security properties, ECC might be a better choice for IoT devices than RSA.

Because asymmetric encryption methods require much more computation than symmetric AES encryption, most systems use asymmetric encryption only for key exchange and then use symmetric AES encryption for basic communications.

ECC and RSA are both asymmetric encryption algorithms. The RSA algorithm is based on the problem of factoring the product of two large numbers. It requires first the generation of large random numbers, checking for primeness, and then multiplying two large numbers. RSA not really an acronym, but an abbreviation of the authors last names – Rivest, Shamir, & Adleman.

Implementing RSA at 2048 bits on a small embedded 32-bit processor is not going to be fast. Multiplication of two 2048 bit numbers requires a 64 word by 64 word long multiply operation. This requires is 4096 long multiply with 64-bit resultant and accumulate (UMLAL) instructions on the M3 or M4 processor, or 32768 multiply with 32-bit resultant (MULS) and add (ADDS) instructions on the M0.

The approximate computation times for a 2048 bit multiply on the Cortex M processors running at 25 MHz are:

• Cortex M4 – 500 us
• Cortex M3 – 1.5 ms
• Cortex M0 – 25 ms

An RSA key of 2048 bits is equivalent to a symmetric AES key of 128-bits. The NSA suite B standard requires a 3072 bit RSA key, which is equivalent to 256-bit symmetric key encryption. The computation time for increasingly higher levels of security increases exponentially using RSA.

Elliptical Curve Cryptography is based on solving the Discrete Logarithm problem. Stated simply, it is not easy to find the discrete logarithm of a point on an elliptical curve. The main benefit of ECC is that it provides a high level of security using a relatively short key. Shorter keys use less memory and dramatically decrease the computational requirements. ECC using a 256-bit key and the 256-bit prime curve is roughly equivalent to RSA 2048.

With a little bit of extra hardware to accelerate modular multiplication, ECC can potentially offer better performance and use less memory than RSA.

Internet security suites provide a comprehensive solution for security which includes key agreement, symmetric encryption with authentication, hash codes, and digital signature. The Transport Layer Security (TLS) specification includes several security suites using different algorithms.

Note that RSA is a full security suite by itself that provides asymmetric encryption and signature. However, the alternatives to using RSA for everything are generally to use one method for key exchange and a different method for signatures.

RSA specified a method for generating key pairs. Rather than using RSA generated key pairs, the alternative is to use the Diffie-Hellman (D-H) key exchange algorithm. This is another algorithm named for the authors - Whitfield Diffie and Martin Hellman.

Diffie-Hellman has some advantages over RSA. However, both RSA and Diffie-Hellman require relatively long keys (2048-bits or more). A variant of the Diffie-Hellman Algorithm using elliptical curve cryptography is Elliptical Curve Diffie-Hellman (ECDH). This key exchange algorithm allows the use of much smaller keys and is well suited for small IoT wireless devices.

The alternatives to using RSA for digital signatures are the Digital Signature Algorithm (DSA) and the variant Elliptical Curve DSA (ECDSA). Again, the elliptical curve variant has the advantage of using a smaller key.

While various combinations are possible, the three passionate solutions are -- use RSA for everything, use DH for key exchange and DSA for signatures, or embrace ECC and use ECDH for key exchange and ESDSA for digital signatures.

Going forward, there is a strong preference for ECDH-ECDSA. Most TLS clients will send a list of security suites in order of preference. The preference for Mozilla Firefox lists ECDH-ECDSA first and RSA as a last resort.

You can check out the Given Cipher Suites supported by your browser using How’s My SSL?

As of this writing, the draft of TLS1.3 does not support using RSA for everything and also deprecates DSA as a signature option. RSA remains as a signature option in combination with DH or ECDH for key exchange.

Diffie-Hellman and Elliptical Curve Diffie-Hellman are favored because they support ephemeral keys and forward secrecy. The Diffie-Hellman algorithm generates a new unique ephemeral key for each key exchange process.

Forward secrecy is a property of a security suite that ensures that if the present key is compromised this does not compromise past session keys. Without forward security, it may be possible to record sessions, then by breaking one key the whole past history is unraveled. 

As proposed, TLS 1.3 will only support ephemeral keys and methods with forward secrecy. DH and ECDH support ephemeral keys and forward secrecy, but RSA does not.

Based on the lower computational requirements of ECC and the desirable properties of Diffie-Hellman key exchange, we predict that IoT products will increasingly use ECDH for key exchange and ECDSA for digital signatures.

IoT Security Part 6: Why should I use Galois Counter Mode instead of CCM?  

The most common authenticated encryption mode for IoT wireless today is CCM, Counter Mode encryption with CBC-MAC authentication. However, the latest and greatest internet security suites support the Galois Counter Mode (GCM) for authenticated encryption.

Instead of diving into the complex finite field mathematics required to implement GCM, lets discuss the motivation for its development. First, consider that security experts will continue to scrutinize existing security methods, find weaknesses, and develop more secure methods. One of these areas is the development of block cipher modes.

After the development of the CCM authenticated mode, there was a big effort to develop a new authenticated mode to follow it. The main criticism of CCM was not security weakness. The main criticism was that CBC-MAC was very computationally intensive and performance was limited because chaining was hard to implement using a pipelined digital architecture.

NIST calls GCM a “High-Throughput Authenticated Encryption Mode”. Is it really? The argument appears to be that GCM computation is easily parallelized.

Suppose we wanted hardware that could compute a Galois MAC over four 16-byte blocks. It is theoretically possible to use four parallel AES cipher blocks and four parallel Galois field multiplication units. This would provide very high performance. However, it is not a realistic scenario for a small embedded processor.

In reality, if you only have one AES cipher block hardware at your disposal and have to implement Galois Field multiplication in software, GCM is much slower than CCM. However, if you have hardware support for modular field multiplication GCM is about the same speed as CCM.

It seems ironic that special hardware is now required to support a block cipher mode that was supposed to provide higher throughput.

This brings us to the situation that we have today. IoT developers would like to use the same state-of-the-art security methods used on PC class internet devices. However, implementing GCM on a typical 32-bit MCU will have poor performance.

The Cypto Module on the Silicon Labs EFR32 Wireless Gecko devices and the EFM32 Pearl and Jade Geckos has a hardware modular multiplier that supports the GCM polynomial. The crypto module has a programmable engine that greatly accelerated the Galois Counter Mode.

There is some synergy between the Galois Counter Mode and the Elliptical Curve Cryptography (ECC) computations. Both GCM and ECC require modular multiplication over a finite Galois field. The only difference is the polynomials.

GCM uses the modulus:

Whereas the ECC prime 256 curve uses the modulus:

The next blog will discuss ECC and its uses for IoT devices.

Secure Hash Algorithm

What is a Cryptographic Hash and why should I use one, instead of a CRC, or Message Authentication Code?

A hash function maps data of an arbitrarily large size to a fixed size. This is essentially a unique fingerprint of the data. A cryptographic Hash Code uses a cryptographic function to generate a hash code. For example, Git repositories use an SHA-256 Hash as a fingerprint to ensure a remote repository is in sync with a master repository.

A cryptographic hash function also has the property that it is not possible to deduce a message from its hash. This is important for security because we might transmit the hash code of data, but don’t want to compromise the actual data.

A Message Authentication Code, or MAC is like a keyed hash. The MAC depends on both parties using the same key. One has to know the key to authenticate the message. A cryptographic hash like SHA-256 has no key. A unique set of data will always produce the same SHA-256 hash code for everyone.

The purpose of a Cyclic Redundancy Check (CRC) is different. CRCs are design to detect errors, not to provide a fingerprint. CRCs are not guaranteed to be unique or protect the security of the content. CRCs are just for error detection.

The most commonly used Cryptographic Hash is the Secure Hash Algorithm (SHA). There are variants called SHA-1 and SHA2. SHA-1 always uses a 160-bit digest. The digest is the output value from the hash algorithm. SHA-2 supports different digest sizes ranging from 224 to 512 bits. Rather confusingly, SHA-2 with a 256-bit digests is commonly abbreviated SHA-256 (perhaps it should have been called SHA2-256.)

So which SHA function to use? Before the NSA introduced SHA, Ronald Rivest designed the MD5 Message Digest Algorithm. Version 5 is still supported by TLS1.2. 

There is some controversy regarding the security of MD5 and SHA-1. For both MD5 and SHA-1 there have been collisions found that limit the security to less than half the digest size. OK. What does this mean?

A collision just means that two sets of data can produce the same digest, or fingerprint. So hypothetically, the odds of having two data sets with the same digest for SHA-1 are slightly less than the ideal value of 1/(2^80). This only means that SHA-1 is not as secure as we thought it was.

There are no known successful preimage attacks on MD5 or SHA-1. A preimage attack tries to find a message with a specific hash. So in that respect, MD5 and SHA-1 are relatively secure.

MD5 is deprecated in TLS-1.2 and SHA-1 is deprecated in TLS-1.3. If you have a choice, I would recommend using SHA-256 (SHA-2 with a 256-bit digest.)

Because TLS connections depend on the capabilities of both parties, it is good to have support for legacy security modes to ensure that you can connect to host that does not support the latest security standards.

The Crypto module on the EFR32 devices and the Pearl and Jade Geckos supports SHA-1 and SHA-2 with a 224-bit or 256-bit digest. If you have a choice, I would recommend SHA-256, because it is just as fast as SHA-224. These devices also support the legacy MD5 Hash using the mbed-TLS software library.

So when should you use SHA? A good use for an embedded device is to use a secure hash for firmware validation. Suppose you have a secure bootloader and you want to make sure that your firmware image is valid. The bootloader might have the capability to calculate a SHA digest for the entire firmware image upon request. The host can compare the SHA digest to the expected value. Because it is a secure hash, we can freely give the digest to anyone that asks for it.

The previous blog discussed the CBC-MAC block cipher mode for authenticated encryption. There are other block cipher methods besides CBC-MAC. The Galois Counter mode is one that is increasing in popularity. This is the subject of the next blog post.

What is an Authenticated Block Cipher Mode?

An authenticated cipher block mode is defined as one that provides both data confidentiality and authentication. But there really are three concepts that are important – confidentiality, authentication, and data integrity.

Imagine we are building a missile control system. We want to send the target coordinates from the control trailer to the launch vehicle over a wireless link. (This is just a hypothetical scenario to demonstrate a point. Don’t try this at home.)

We want to encrypt the coordinates using AES so that the enemy cannot eavesdrop and know the coordinates. If we use the correct key and the encryption and decryption are both perfect, the launch vehicle will get the correct coordinates.

However, consider what happens if the launch vehicle has the wrong key, or something else goes wrong with the decryption. The launch vehicle will fail to decrypt the data, but launch vehicle has no indication that the decryption operation failed. The output of a failed decryption is random garbage. So the launch vehicle will take the random coordinates and fire the rocket.

Authentication solves this problem by appending a Message Authentication Code (MAC). Authenticated modes use the same key for encryption and authentication. If the MAC checks out, we know that the decryption was successful. 

Counter Mode with CBC-MAC (CCM) uses the counter mode for encryption and the Cipher Block Chaining (CBC) mode to generate the Message Authentication code. The CBC mode chains the output of the last block operation and exclusive ORs in with the plain test input.

The CBC-MAC mode uses zero for the initial vector and only uses the final ciphertext as the message authentication code.

The cipher block chaining mode differs from the counter mode in that the output for each encryption operation depends on all the previous data. This is just what we need to generate a Message Authentication Code. After feeding in all of the blocks, the final output from the CBC mode is the MAC.

If the authentication passes, this tells us a lot about the data. We know that it has been successful encrypted and decrypted. It ensures both parties are using the same key. It also ensures that both parties know what they are doing. Both parties agree on the IV and the nonce and all the details of the encryption process.

Authenticated encryption provides authentication, data integrity, and data confidentiality. Because the sender knows the correct secret key we know the message is authentic. By transmitting only the encrypted data we provide data confidentiality. A third party eavesdropping on the transmission cannot decipher the data without the secret key.

The MAC also provides a measure of data integrity. Because a single bit transition error will cause the authentication to fail. This indicates that the message has been has been transmitted and received perfectly without any errors.

Because CBC-MAC uses the 16-byte block cipher, the MAC will be 16-bytes. This is OK if the message is many blocks long. If the message is only one byte long, there will be 15-bytes of padding and a 16-byte MAC. This means we always have to transmit 32 bytes of encrypted data for 16 or fewer bytes of plaintext.

CBC-MAC is used for authentication for many wireless networks – ZigBee, Bluetooth Smart, Thread.

Authentication requires a shared secret key. However, sometimes we just want a unique fingerprint of the data that does not require a shared secret. The next blog will discuss the Secure Hash Algorithm, and don’t forget to check out the previous blog in this series.

A cipher block mode is a method of manipulating blocks of data using the AES cipher to improve security. The AES cipher is an atomic operation on 128-bits of data. Normally the plaintext goes into the cipher and the ciphertext comes out of the cipher. But there are other ways to use the cipher.

Why should we use a block cipher mode? First, consider the case where we are encrypting many blocks of data. If we encrypt data using the same key every time and using the same method, we give a clue about the encryption. If we just use the basic cipher in the electronic code book mode using the same key, we are opening ourselves up to a black box brute force attack.

The block cipher modes mix it up a bit. Each block of data is encrypted differently than the last block. This makes it harder to guess the encryption key. It is effectively like using a different key each time. For data security encryption, the most commonly used cipher block mode is the counter (CTR) mode.

The counter mode uses the basic cipher in a convoluted way. Instead of encrypting the plaintext, the cipher encrypts the counter value. The counter value is concatenated together with a Nonce before encryption. A Nonce is a “number used once” and is similar to an initialization value. Both the sender and the recipient must use the exact same Nonce for it to work. The output from the cipher is exclusive OR’ed with the plaintext.

The exclusive OR operation is very commonly used in block cipher modes. Any time plain text is exclusive ORed with some secret key, it is impossible to determine the original key from the ciphertext. This is known in cryptography as a One Time Pad.

The counter mode potentially improves the security of the system by extending the 16-byte AES cipher to an arbitrary long cipher. It converts a block cipher to a stream cipher. To decrypt data encrypted using the counter mode, we need to know the key, the Nonce, and the block count.

Because the block count changes each time, the encrypted data for each block is unique. Suppose we encrypted the same 16 bytes of data repeating four times. The electronic code book (ECB) mode would be to just apply the AES cipher to each block of code. When using the ECB mode, if the data repeats, then the encrypted data will also repeat. Unlike the electronic code book mode, the counter mode encrypted data would not repeat.

If data changed only one bit each time, the ECB mode might give use information that will help us guess the key. Changing one bit each time using the counter mode will not give us much information. The CTR mode provides protection against a Replay attack. A replay attack is a systematic cryptographic attack that involves eaves dropping on a conversation, and then playing back part of the encrypted conversation, a password for example. If the counter value is different each time, this ensures uniqueness.

In IEEE802.15.4 networks, the counter value starts at zero and increments for each block in the payload. The Nonce security material includes the frame counter and the key sequence counter. The frame counter increments with each frame transmitted. Thus, it is the Nonce and not really the counter value that establishes a session and ensures session uniqueness.

Theoretically, the counter mode allows random access. Suppose we encrypt data and store it in an external Flash using CTR mode. We don’t have to decrypt the entire Flash from the beginning. We can just read out the block we want, use the address for the counter value, and decrypt it.

There are several different methods to implement counter mode on an MCU with built in AES encryption. The method will depend on the hardware resource of the particular MCU. The Gecko devices have an AES block with XOR capability. The AN0033 explains the Block Cipher Modes in detail and how to implement them on EFM devices.

The new Wireless Gecko EFR32 SoCs and the Pearl and Jade Gecko 32-bit microcontrollers have a Crypto module, which has programmable hardware to implement the different block cipher modes. This improves performance and minimized the amount of software computation required.

Most authenticated block cipher modes use the counter mode for encryption and the cipher block chaining mode for authentication. The CBC mode for authentication will be the subject of the next blog, and don't forget to check out the previous installment in this series. 

Alex,

Thanks for your comment.

For BTLE, normally security is handled at the Application layer. The BTLE stack can provide AES-128 encryption services, but only if the Application layer uses it.

This means that the low-level MAC header and address are sent in plain text, but the application data payload may be encrypted.

We provide a basic OTA bootloader with our BTLE stack. If the OTA bootloader is used with Application layer security, then the over-the-air data is encrypted.

BTLE uses AES-128 with CBC-MAC for encryption and authentication. So the encryption is 128-bit strong and the authentication prevents message tampering.

We are working on more advanced solutions for OTA and firmware bootloaders with encryption, authentication, and digital signatures.

If you need more details or help with the Blue Gecko products, please create a support ticket:

https://www.silabs.com/support/pages/contacttechnicalsupport.aspx

Cheers,

Ken

Thanks for the comment.

Yes. I agree that default passwords are a big concern.

We have 256-bit AES encrpytion on our MCUs, but an application will not be secure if the password is left as "admin".

Cheers,

Ken

This bug has been fixed. Thanks for your feedback.

Please download the latest firmware from the website.