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 ...


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 ...


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 not a worry for "...


6

Most microcontrollers that are suitable for crypto I've seen have a variant with a hardware RNG. For example the PIC32 series by Microchip. However, if not, what you could do is attaching some sensor to an ADC. It would depend on your environment what kind of sensor you could use. It can be anything, which is not easily manipulated (at least not in the LSB(...


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

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 ...


5

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. ...


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

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 ...


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

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 ...


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 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. ...


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

Is there a way to break this exponentiation into smaller exponentiations that the modular exponentiation function can handle? Yes there is. Normally one would do this with pre-computatations to process more than one bit of the exponent per iteration, but it should nicely adapt to your case. In particular I suggest you use algorithm 14.82 from the ...


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

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

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

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 ...


1

The answer is to your problem is called Transport Layer Security with Pre-Shared Keys (TLS-PSK) and is widely available in implementations. TLS-PSK offers PKC aided and non-aided key-exchanges, with the former being recognizable by the DHE, ECDHE, RSA parts in their names. This means you want to look for the TLS_PSK_WITH_* cipher suites. In particular I'd ...


1

An issue with storing a key in RAM is, there are attacks that involve erasing the flash to unlock the device and then using a debugger to copy the RAM contents. Problem with internal EEPROM is the same as RAM unless you can lock it. External EEPROM is worse, unless you encrypt that. My druthers would be store the key in flash and then lock the lock the ...


1

First, if you mean to sign something, you should use a signature algorithm, rather than "RSA encryption" with private key, which on its own may be very weak. Now the main issue here is that the RSA part is only authenticating the nonce. Anyone who knows the AES key can just encrypt an arbitrary firmware image with a nonce they've already seen. This allows ...


1

I have done some experiments here: https://github.com/kuro68k/xrng TL;DR using the LSB of an Atmel XMEGA's internal temperature sensor and VCC/10 inputs to the ADC, then feeding that through a CRC32 algorithm for whitening resulted in an RNG that passed Diehard, NIST's tests and looks good in ent.


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