10

Signature algorithms of the ECDSA family are amenable to precomputations. Indeed, when you want to sign message m with ECDSA, the process goes thus: We work in a curve (or a subgroup of a curve) of order $n$ (a prime integer). A conventional generator $G$ is given (a fixed point of order $n$). Private key is $x$ (a non-zero integer modulo $n$) and public ...


10

I second Richie Frame's observation that AES is an excellent choice. I'd use AES-128 in CTR mode, which has the advantage that decryption is the same as encryption (thus is as fast, contrary to some other modes). Update: SPECK, considered in this other answer, is good if compactness or speed per encryption for narrow block size are the choice criteria. ...


9

SPECK was actually designed with 8-bit CPUs in mind. I use Simon and Speck extensively, and there's example source code and comparisons out there, as well as a good paper. The references are good and will lead you the the original sources. AES is generally faster but takes more resources, which you may or may not have. I do not use AES on a MCU because ...


8

Is there any worthwhile way to authenticate the message using only these functions and simple checksums? As usual, of course there is: AES-CCM! AES-CCM basically is CTR mode with a tagged-on CBC-MAC and length prepending. You can implement CTR trivially using your ECB primitive and CBC-MAC shouldn't be too hard to implement given a CBC primitive and direct ...


8

The simplest way to deal with replay attack prevention (in some narrow sense of that, where the goal is to avoid that the receiver allows the same command to be played to it several times) is to have an incremental counter in an authenticated section of the packet, incremented by the sender before forming a packet to be sent. The receiver checks the ...


7

Given that the bottleneck on the embedded device is local non-interactive public-key signature verification, the best industry standard for that is RSA (with a standard signature padding, such as PKCS#1 RSASSA-PSS, PKCS#1 RSASSA-PKCS1-v1_5), which is usually significantly faster than ECDSA for signature verification including for the common $e=65537$; and ...


7

A BN-curve over a 256-bit prime field $\mathbb{F}_p$ has, being an elliptic curve, a 256-bit group attached to it, say of order $N$. As the best known attacks take $\approx\sqrt{N}$ times, this gives us 128-bits security against discrete logarithm attacks. The curves also have embedding degree 12. That means we can use a pairing to map a discrete logarithm ...


6

No, use SHA256. If you look at https://bench.cr.yp.to/results-hash.html it seems that SHA256 would probably be the better choice concerning speed as well. Therefore I don't see a good reason to go with SHA-1.


6

There is no real problem with applying "false start" to PSK cipher suites. The "false start" thing is about beginning to use the negotiated key to encrypt data before having confirmation (with the Finished message) that the peer really agreed on the same key. In that sense, the peer authentication is still implicit at that point. This is ...


5

Fgrieu has already posted a good answer, which I won't try to repeat. However, here are a few additional observations: For an embedded system, you may want to consider using CMAC-AES instead of HMAC, since you can reuse your AES implementation, and don't need a separate hash function. Further consider using SIV mode (RFC 5297). It's very similar to CTR+...


5

Generally you should try and avoid deriving keys from passwords on embedded devices or passwords. There are a few strategies that could be used. First of all, you can try and design a system that doesn't use a password. Passwords are very tricky to secure, and password hashing algorithms (or, in this case, rather Password Based Key Derivation Function or ...


4

I understand the system as follows: data blocks are enciphered per AES-CTR, using key encryption_key, with an IV made by concatenating device_id and a counter held in Flash or EEPROM, incremented at each use; that enciphered data is integrity-protected by a 256-bit mac_tag computed using HMAC-SHA256 and mac_key. That's theoretically sound if device_id is ...


4

I do not have benchmarks on this particular processor, so this answer is opinion / guesswork. Gimli is fast and low-memory, but is just a permutation. Ciphers can be pretty trivially implemented on top of it though. It was designed to be efficient on a wide variety of hardware, and there is a reference implementation for an 8-bit AVR microcontroller. ...


4

Yes, if you already have a shared symmetric key then this would be something to consider. Note the following: you do not need to store a private key in the embedded systems in your previous scheme; the security of the key generating the signature is probably more important than the key providing confidentiality of the update (updates are often not ...


4

There aren't many KDFs that will be faster on an AVR than PBKDF2. In your case, it's likely that the only thing you can do is find a hash which can be implemented efficiently on an ATmega2560, and implement it with as many optimizations as possible. A highly-optimized implementation of a hash algorithm is likely to improve speed significantly. That's really ...


4

Can a passive listener break this encryption and/or craft legitimate messages? A passive listener should not be able to reverse AES, so getting the plaintext should be impossible, unless each session is restarted. However, this scheme would be vulnerable to plaintext oracle attacks. Read on. As for crafting legitimate messages: that's not a passive attack. ...


3

The title says authentication, that is we want only the real firmware to load and run, unmodified. There are fast, practical code signature techniques for that. Most importantly they require no secret in the target device. The baseline would be that the target contains an RSA 2048-bit public key with $e=3$, and uses that to verify an RSASSA-PKCS1-v1_5 ...


3

Unless you have documentation about the RNG interface that states that it's using a cryptographic PRNG seeded by an entropy source, use it only as a seed to a PRNG. (Seed initially, and re-seed from time to time as directed by the PRNG algorithm and possibly by certification requirements. Since you're using an existing PRNG library, just pass it the seed ...


3

A rule in cryptographic protocols is to never implement them on your own. Unfortunately I did not find anything that matches this use case. Have you considered DTLS? That tries to address the same problem (except for time stamps; that could be added by inserting the time stamp in the datagram), and already has things thought through. Another possibility ...


2

One alternative to RSA that may bear looking at is hash based signatures, perhaps as worked out in this IETF draft. Here, the signature validation consists of evaluating a series of perhaps a few hundred hashes. I'm not certain how fast your CPU can evaluate a hash (or an AES encryption, which the draft allows to be used instead of a hash), however I ...


2

I've finally found a solution - some variants of key ratcheting, e.g. the one used in SCIMP, provide perfect forward secrecy assuming an initial shared secret is established without any asymmetric crypto, and they don't even require a secure random number generator on any of the endpoints! In this case all we need for an authenticated and encrypted protocol ...


2

As stated in the comments we can't / won't advise on whether PolarSSL is suitable to perform the operations required. However, for your needs $N_1=N_2=N_3=32$ sounds like a reasonable choice, giving you a solid 256-bit security and no need to worry about truncation and the alike. As for $f_1$, HMAC-SHA256 sounds like the obvious choice, also giving you $...


2

Considering the OP specifically mentions replay attacks, which I believe requires a unique CTR for replay protection even with SIV mode, then I believe SIV may only create a potential false sense of security and more complicated and maybe less flexible code than, say, something like EAX mode or based on EAX mode (EAX mode makes more sense to me than GCM for ...


2

I think you are confusing something in the mbedTLS ssl_client1 example. The example does not specifiy the server certificate, but the CA (Certificate Authority) certificate. The client loads the CA certificate into its CA chain. Later on it still requests the certificate from the server (ssl_handshake step) and uses the public key inside the CA certificate ...


2

As cheaper alternatives to HMAC with modest security goals, consider: SipHash—cheaper than MD5 because you don't have to pay for collision resistance; security is limited by the 64-bit output size Maybe a Gimli-based PRF—Gimli is a new compact design Derive a fresh key for each message, and use a one-time authenticator like a polynomial evaluation universal ...


1

One method uses the factorisation the exponent: If $a=bc$ then $x^a \equiv x^{bc}\equiv (x^b)^c \mod m,$ i.e. first compute $y=x^b\mod m$ and then $y^c \mod m$. This method will work, if the largest factor of the exponent has at most 32 bytes. Otherwise you can always use the square-and-multiply exponentitation method (see https://en.wikipedia.org/wiki/...


1

I believe Roel Maes gives a very good answer to your question in his PhD thesis, pages 20-23. In essence, ideally, you need to calculate an array of the Hamming Distance between every pair of responses to the same challenge. Those pairs correspond to either the same chip or different chips depending on if you are looking at intra- or inter- distance. Both ...


1

Part of the TLS handshake is that the server sends the client its certificate before setting up the secured connection. The client should verify that the certificate is valid, e.g. check whether the CA has indeed signed the certificate, whether it has not been revoked/expired, etc. It would not make much sense to fetch the certificate from the CA, as the ...


1

For my answer, I'll assume that you have symmetric keys pre-shared between your heater and your sensors. If your devices have enough computational power to support asymmetric cryptography (which will increase workload by a large factor and message length by at least 32 bytes) the answer will be different (and provide stronger guarantees). AES-128 CCM is a ...


Only top voted, non community-wiki answers of a minimum length are eligible