I am trying to use asymmetric encryption to encrypt firmware. The bootloader will decrypt and update the flash. This is on a embedded device with 32 bit CPU executing at 60MHz.
I want to use ECC due to its varies advantages. I am new to encryption and my understanding os ECC as implemented in ECIES is to use ECC for the key generation and use AES for actual data encryption. Due to code and ram size, I cannot support multiple encryption algorithms.
Is there a implementation of ECC that can be used just like AES. All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
Thanks.
I'm not sure that you completely understand what ECIES consists of:
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme
That's quite a bit of work, and it requires a whole lot of primitives, including at least one symmetric primitive, it seems to me. That might as well be AES.
Let's start from the last sentence of the question:
All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
There's some confusion in terminology here. Private keys are used to decrypt (or sign) and public keys are used to encrypt (or verify). If I understand correctly, what you want is for the bootloader to verify a signature on the firmware so that only a firmware that was properly signed by yourself will be accepted by the bootloader.
There are various asymmetric signature schemes which can be used for this purpose, including some which are based on eliptic curve cryptography. For example you could use the OpenSSL implementation of ECDSA (see http://www.openssl.org/docs/crypto/ecdsa.html).
I'm afraid there's not enough information in the question to properly choose the best signature scheme (and possibly an encryption scheme as well if there is a need to keep the firmware secret). In any case, good cryptography is not enough to make a system secure and other considerations such as secure implementation are no less important.
If this is is something that is important for you to protect and that you are worried that hackers may try to break, I would strongly advise procuring the services of a security professional. Using cryptography correctly is a very tricky business that requires a full understanding of the system - otherwise you may find yourself in a situation like this
If you look for "authentication" you have to use asymmetric algorithm like EC, this usually done because if the user or process want to update the "firmware" he should identify him self to the bootloader by his "signature" to check who request this update.
After that is done, the bootloader will load the symmetric key from a secure memory to decrypt what you want to do.
So, you have a symmetric key for encryption (AES), and asymmetric two keys for authentication (=Who are you?).
Note: there is no advantages of EC on 32 bit CPU executing at 60MHz for Encryption, unless your application need asymmetric for Encryption NOT authentication, this happen due to line between the user and bootloader is not secure.
Therefore, you could use bootloader's "public key" to encrypt firmware and the bootloader uses its "private Key" to decrypt it, however, the implementation cost a lot due to the high computing for asymmetric algorithm.
Look for "lightweight cryptography", it is typical for your application.
Related
I'm working on a project that take the GPS location every 5 seconds and send it to the server, but i need to make a little of security, so i need to encrypt the location in android device and decrypt it in server side, so i'm searching for a simple algorithm to do this
Thanks in advance
The ideas for you to try:
Send your data over HTTPS. It will add the layer of security you need and it's one of the simplest methods available.
Use Java Encryption API with asymmetric cryptographic algorithm like RSA. You should probably avoid using AES or similar symmetric algorithm because you should not store passphrase in your Android app - it could be quite easily compromised.
Introduction:
For my personal webserver I have setup apache with a self signed certificate to enable TLS security to learn and test.
I have this line in virtualhost:
SSLProtocol -all -SSLv3 +TLSv1
SSLCipherSuite TLSv1:+HIGH:!MEDIUM
With firefox, I get Camellia-256 encrypted connection, and with opera I get TLS v1.0 256 bit AES (1024 bit DHE_RSA/SHA) with the same config in same server.
That leads me to question, which is stronger, AES, or Camellia?
I noticed that if I disable camellia with SSLCipherSuite TLSv1:+HIGH:!MEDIUM:!CAMELLIA then, firefox takes the same suite than opera.
In my config, I also try to disable all SSL versions to enable only TLS (advise needed if I didn't do so correctly), but the original question still stands: Which one should be stronger?
I would be more worried about the fact that your SSL encryption is not secure because you are only using 1024 bit asymmetric encryption to protect your keys.
Adi Shamir (the 'S' in RSA) recommended moving to 2048 bit keys back in 2006, even the american standards institute (NIST) have made 2048 bit a required minimum strength since January 2011 (see NIST SP800-57 for recommended minumum key strengths -- this states 2048 bit for both RSA and DH/el-gamal).
In short, make sure your RSA encryption is strong enough first, as it is used to protect the symmetric keys (AES/Camellia). Never rely on a key which is protected by a weaker key (this is like using a secure 256 bit random WPA 2 key on a wireless access point and then trusting it to WPS which will reveal in in a few hours!)
Even if this is a test system, learn to use crypto the way you intend to go forward; do not compromise on certificate key strength (all CAs these days should reject 1024 bit requests or CSRs using MD5 on sight, if not don't use them; create your own test certs as you would a real request, and don't use default key sizes).
Difficult to compare strengths, both have received cryptographic analysis (AES more publicly) and are adequate for securing data.
At the risk of repeating myself, I’d be more worried about the 1024 bits used to secure the key negotiation.
It's hard to judge the strength of these algorithms. Camellia is considered roughly equivalent to AES in security (source). In any case, the difference probably won't matter. Either algorithm is secure enough to make your data channel no longer be the weakest link in your system, so you don't need to bother modifying any configuration.
The OpenSSL cipherlist TLSv1:+HIGH is a really bad choice. The "+something" notation means move all the ciphers that match "something" to the end of the list.
Therefore, you're using HIGH only as a last resort, with anything that's not HIGH preferred.
A much better choice is "DEFAULT:!MEDIUM:!LOW:!EXPORT:+3DES", which starts with sensible defaults, removes MEDIUM, LOW and EXPORT, and uses 3DES last (which it probably is anyway, but on some systems it comes before AES128 because it may be considered to be 168-bit strong).
We are putting an HTTP RESTful interface into an embedded platform of ours. The hardware is too limited to support SSL, but we do use AES encryption for other things.
I'm thinking of using AES with a shared key to encrypt the data. Is there anything else that is at least a somewhat standard way of encrypting via HTTP?
The standard way of encrypting HTTP is SSL (or its successor TLS, nowadays) (this is then known as HTTPS).
As GregS asked in a comment, in what way is your platform too limited for SSL, but still allows AES? Does it have not enough computing power/memory to do modular exponentiation (which is used in RSA, DSA, Diffie-Hellman)?
Then you might be able to use a pre-shared key version of TLS. RFC 4279 defines cipher suites with pre-shared key authentication, where the TLS_PSK_WITH_AES_128_CBC_SHA looks like if needs only AES and SHA-1, no modular exponentiation.
Of course, you shouldn't use this if there is the danger that an attacker can get the secret (e.g. by cracking your device), since this allows also to read all previously registered connections (in contrast to Diffie-Hellman, which provides a new session key for each session).
Found this gem: Diffie-Hellman Key Exchange in 10 lines of C
http://www.cypherspace.org/rsa/dh-in-C.html
I have a pair of transceivers connected to the micro-controller from Port A, and a MM232R connected to Port B on a separate PCB. Each transceiver will send encrypted data, while MM232R will receive a decrypted data. I need write encryption algorithm and decryption code. Can anyone give me idea on how to go about it? I am new to programming and encryption algorithm.
I'm not sure about the ROM/RAM limits of the PIC18F1320, that is the main constraint.
This page contains an implementation of AES on a PIC18F4620. It uses 2K words of ROM and 240 bytes of RAM.
This other page seems to have an implementation of RSA on a PIC18F4550, but it warns that it is very slow (which does't surprise me, since RSA encryption requires modular arithmetic on large integers).
I just installed a SSL certificate. This certificate is encrypted with 2048 bit encryption.
However, the cypher is 128 bit encryption(or 40, or some other variation depending on the browser.)
It seems that there are two different types of encryption here. The "handshake" encryption of 2048 and the "over the wire" encryption of some magnitude smaller.
Do I have this right in theory? Can anyone explain it better?
I have been all over the Google and cannot find a clear explanation of the difference between the two.
There is a good entry in Wikipedia.
You are right, there are two kinds of encryption going on. The first one is asymmetric encryption or public key encryption - this is the one with the larger key. The second type is symmetric encryption with the smaller key.
The first type of encryption (asymmetric - larger key) is used to negotiate what type of symmetric encryption the client and the server will use. They'll also exchange the session key that they'll use. This is the handshake process and this is encrpyted using the asymmetric encryption
The session key is basically the key that they'll use when sending the real data, encrypted by whatever type they've decided on the handshake process. This is the symmetric encryption part.
It is true that symmetric encryption typically uses much fewer bits for its key length. The reason is because symmetric encryption is much stronger at a given number of bits.
Asymmetric encryption (where each side has a different key) is much harder to pull off. It is more computationally intensive and therefore only used for the handshake portion or for encrypting a symmetric key that the rest of the message uses.