good encryption chips for wired communications?

[jbb]

I think that what you want does not exist in chip form.  Good crypto in embedded is hard, and takes hard work.  If you don't want to get in it up to your eyeballs, maybe you should look for a 3rd party system (hardware, software, keying material, instructions and policies etc.) with appropriate standards compliance?

I want no part in generating or maintaining any kind of key database.

Then you are doomed to failure.  Key management is absolutely critical, and you can't rely on the end user to 'know what to do.'  If you're lucky, you can get them to follow your explicit and carefully written instructions and procedures.  Which means you must take some part in key management.

The thing is declassified and you just have some kinda slot for the key to go into I guess, I never really looked at it, I know you can buy em though.

And how is this dongle loaded with keying information?  How do you know it hasn't been tampered with?  How do you know that all the dongles aren't just I2C EEPROM chips with the same key every time?


radioactive has kindly made a list of some standards.  I suggest you have a look at them.

Off the top of my head, a quick set of considerations for the crypto:

• Accept that there will be a number of keys per device for various roles (e.g. communications vs pairing vs firmware update).
• Don't use DES.  It's old and the keys are too small.
• Use AES128 or AES256.
• Use hardware for encryption and authentication.  Software implementations leak information out (execution time, power supply ripples, RF radiation, ultrasonics, I'm sure people will find more).  Hardware implementations are constant-time (and faster than SW!) and leak less information.  Modern micros often have hardware built in, just add device drivers.
• Use cryptographic authentication to make sure someone hasn't tampered with the data in flight.  Even if they can't read it, someone randomly flipping bits might cause a Very Bad Payload after decryption.  CRC is not cryptographic authentication.  You most likely need an AES HMAC or something from the SHA-2 family.
• AES keys must be unique per device.  Otherwise someone can break one unit, and extract the One Key to Pwn Them All.
• Private RSA or ECC keys must use be unique device.  See above
• Wherever random numbers are used, they need to be strong.  They should come from a hardware (a.k.a. 'true') random number generator and should probably have some whitening.
• AES keys should be managed with a finite life (both in calendar time and number of blocks encrypted), after which they should be retired.
• All plaintext keying information must stay inside the micro unless it's encrypted.  Be careful if using external RAM - special linker scripts may be required to manage the exact placement of key material.
• Unique serial number per device.

This is by no means exhaustive.

I suggest you take a look at the MBED TLS software library.  I believe the DTLS option can send data without TCP/IP, but still do the good stuff like public key exchange (I suggest TLS_ECDHE_ECDSA_AES_GCM_128).  However, you need to either a) get yourself a preconfigured software library for your processor and review the #### out of it or b) hook the MBED TLS library into the hardware on your chip (coding required).  Option c, which I don't recommend, does the AES, SHA etc. crypto primitives in software and be more vulnerable to side channel attacks.

Deployment of TLS like this will also require certificate management, which includes key handling.  There's no way to avoid it.

In addition to all this, you must be able to update the product firmware in a secure manner.  This means some kind of signature.  Seeing as you don't want to prepare a separate update binary for every damn unit, you will need to deploy public key cryptography techniques (e.g. RSA or ECC).  Typically you would load a manufacturer public key into every device (same for all devices is OK for public keys) and sign the firmware binary with the manufacturer private key that you keep in a vault.  Also, bonus points if you encrypt the payload so people can't read your binary.

EDIT: oops, I forgot replay protection.

[coppercone2]

AES is a symmetric key algorithm, not private/public-key. I agree with all the others here that you seem to have little understanding of what you're trying to accomplish.

where the hell did i say anything public? I said no externally adjustable data at all, not even timing negotiation in the protocol

no one said anything about me not knowing what I am wanting to accomplish, they just keep bringing up issues related to key management, physical security and generation that are literary not my interest or problem. Anything related to loop area in semiconductors can be nulled with distance, isolation, guards and shielding.

I am looking for some bit-shifters with very specific information flow and speed (encoder/decoder) not a EZ CRYPTO SOLUTION

why are you even upset?

[coppercone2]

I think that what you want does not exist in chip form.  Good crypto in embedded is hard, and takes hard work.  If you don't want to get in it up to your eyeballs, maybe you should look for a 3rd party system (hardware, software, keying material, instructions and policies etc.) with appropriate standards compliance?

I want no part in generating or maintaining any kind of key database.

Then you are doomed to failure.  Key management is absolutely critical, and you can't rely on the end user to 'know what to do.'  If you're lucky, you can get them to follow your explicit and carefully written instructions and procedures.  Which means you must take some part in key management.

The thing is declassified and you just have some kinda slot for the key to go into I guess, I never really looked at it, I know you can buy em though.

And how is this dongle loaded with keying information?  How do you know it hasn't been tampered with?  How do you know that all the dongles aren't just I2C EEPROM chips with the same key every time?


radioactive has kindly made a list of some standards.  I suggest you have a look at them.

Off the top of my head, a quick set of considerations for the crypto:

• Accept that there will be a number of keys per device for various roles (e.g. communications vs pairing vs firmware update).
• Don't use DES.  It's old and the keys are too small.
• Use AES128 or AES256.
• Use hardware for encryption and authentication.  Software implementations leak information out (execution time, power supply ripples, RF radiation, ultrasonics, I'm sure people will find more).  Hardware implementations are constant-time (and faster than SW!) and leak less information.  Modern micros often have hardware built in, just add device drivers.
• Use cryptographic authentication to make sure someone hasn't tampered with the data in flight.  Even if they can't read it, someone randomly flipping bits might cause a Very Bad Payload after decryption.  CRC is not cryptographic authentication.  You most likely need an AES HMAC or something from the SHA-2 family.
• AES keys must be unique per device.  Otherwise someone can break one unit, and extract the One Key to Pwn Them All.
• Private RSA or ECC keys must use be unique device.  See above
• Wherever random numbers are used, they need to be strong.  They should come from a hardware (a.k.a. 'true') random number generator and should probably have some whitening.
• AES keys should be managed with a finite life (both in calendar time and number of blocks encrypted), after which they should be retired.
• All plaintext keying information must stay inside the micro unless it's encrypted.  Be careful if using external RAM - special linker scripts may be required to manage the exact placement of key material.
• Unique serial number per device.

This is by no means exhaustive.

I suggest you take a look at the MBED TLS software library.  I believe the DTLS option can send data without TCP/IP, but still do the good stuff like public key exchange (I suggest TLS_ECDHE_ECDSA_AES_GCM_128).  However, you need to either a) get yourself a preconfigured software library for your processor and review the #### out of it or b) hook the MBED TLS library into the hardware on your chip (coding required).  Option c, which I don't recommend, does the AES, SHA etc. crypto primitives in software and be more vulnerable to side channel attacks.

Deployment of TLS like this will also require certificate management, which includes key handling.  There's no way to avoid it.

In addition to all this, you must be able to update the product firmware in a secure manner.  This means some kind of signature.  Seeing as you don't want to prepare a separate update binary for every damn unit, you will need to deploy public key cryptography techniques (e.g. RSA or ECC).  Typically you would load a manufacturer public key into every device (same for all devices is OK for public keys) and sign the firmware binary with the manufacturer private key that you keep in a vault.  Also, bonus points if you encrypt the payload so people can't read your binary.

So you are saying that people don't pin their locks or make their own keys?

Good tips but key management aint my problem. Idea is to have as little software as humanely possible. You can make money managing anything really. And I consider it fucked if someone gets within 200 feet.

I am just interested in ASIC encoders/decoders at this point. I am thinkin about this programming stuff with a fresh mind this morning and I would rather not lol

You used too many scary words man:
1) MBED TLS software library. 
2) DTLS option
3) TCP/IP,
4) public key exchange
5) TLS_ECDHE_ECDSA_AES_GCM_128)
6) preconfigured software library for your processor and review the #### out of it
7) hook
MBED TLS
9) library
10)  (coding required).    
11)  AES, SHA etc. crypto primitives
12) software


I could make a scary video montage out of these words, like the scam montage in Better Call Saul, I am seeing captain hook steering his ship around in a bowl of alphabet soup fighting neolithic people over clothing.. then at the peak of the action when your sitting on the edge of your seat some grey monoliths come down from the sky speaking of hundreds of errors in the compiler

[coppercone2]

try getting the data sheet thats the problem. those suckas abridged it. They demand mucho dinero and lawyers for the real specification

Seeing how that chip is export restricted, they're probably covering their @$$es. Your complaint should properly be directed against the federal government where those laws originate. You can't blame Maxim for trying to make sure they're not a co-defendant in some federal lawsuit because some nitwad used their chip and then exported their system in violation of federal law.

Uh, so do you think they will sell that thing? I mean do they just think you won't be able to figure it out with random IO? I assume you can at least figure out which port is SPI or I2C and power or whatever by its impedance and comparing it to similar chips, even if you don't have a xray. They sell an entire line of chips that are kinda related in their product line that might use the same silicon.

Way too complicated to fuzz some kind of logic map of the interior? (only heard about this theoretically).

Or is mouser going to bring you to some special page when you wanna buy it (I never bought anything export controlled other then power microwave stuff on eBay, probably because it was used in EW labs, and it just threatened me a bunch with fines and jail IIRC, unfortunately a ninja did not come out of my computer and force me to take a ancient blood oath, I really thought one might with all those cryptic legal symbols)

Is it true they make you burn a picture of the virgin mary in your held out hand when you finally get top secret clearance at kinky hazing ritual with Gina, Nakasone and Trump? Maybe i'd do it if they were all like 20-30 years younger. 

[Mr. Scram]

Coppercone2, I understand that you feel that people here aren't answering your questions. However, considering that there are a lot of very experienced people here and quite few have warned you that encryption is an involved affair that requires knowledge and experience, might it be an idea to now take a step back and take a long hard look at what you're trying to do, how you're going about achieving it and how feasible it really is?

Nobody's trying to be hard on you, but security requires designing it in from the start. Building hardware and sprinkling it with secure chips first seems to be a recipe for disappointment. Please understand that people are trying to help you and that being increasingly belligerent isn't serving your goals.

[coppercone2]

Most things on this forum are actually really hard. All I learned from this thread is that you can refer to them as decoders/encoders (for some reason I thought the term excluded encryption operations for whatever reason) and that most people prefer to use software to do the encoding and decoding. And that the goverment finds those chips interesting for whatever reason, enough that apparently Maxim SC yields to their pressure.   

I am just surprised people will talk shop about atomic clocks, cutting edge voltage references (which don't usually turn into discussions about how mass producing a ship able DMM is difficult), but some kind of arithmetic chip turns into a huge debacle. I think I phrased my question wrong and used incorrect unspecific vocabulary, so this very general discussion happened, and I failed to focus.

 I think this is also because there is a massive cryptonerd war (usually related to PC's though) that's been going on for a very long time about how to make a better mouse trap and how everything else is utter shit, so this thread seems to reignite some of that passion in people when the question is not focused.

When I do more industry research and general research on algorithms handled by ASICs I will make a more specific thread with specific chip requirements if I still cannot find what I am looking for, where I will compare my requirements to specifications that can be met with some of the devices people listed in this thread compared with my own sizing up of the classified datasheet ASIC.

This thread can just live as a re purposed (hijacked) warning (and useful guide) to those interested in the whole enchilada rather then just the algorithmic subsystem of a typical encryption system that I am interested in. I do feel that there is generally useful information here.

 I can't say the points are useless but they feel mostly irrelevant to my interests in the ASIC technology. I also have never seen a encryption system design/engineering/development thread on EEVBLOG before so there might have been superheated interest in the topic that caused this chaotic precipitation of information on the nucleation point that is this thread.

[jbb]

Most things on this forum are actually really hard. All I learned from this thread is that you can refer to them as decoders/encoders (for some reason I thought the term excluded encryption operations for whatever reason) and that most people prefer to use software to do the encoding and decoding. And that the goverment finds those chips interesting for whatever reason, enough that apparently Maxim SC yields to their pressure.   

I am just surprised people will talk shop about atomic clocks, cutting edge voltage references (which don't usually turn into discussions about how mass producing a ship able DMM is difficult), but some kind of arithmetic chip turns into a huge debacle. I think I phrased my question wrong and used incorrect unspecific vocabulary, so this very general discussion happened, and I failed to focus.

 I think this is also because there is a massive cryptonerd war (usually related to PC's though) that's been going on for a very long time about how to make a better mouse trap and how everything else is utter shit, so this thread seems to reignite some of that passion in people when the question is not focused.

When I do more industry research and general research on algorithms handled by ASICs I will make a more specific thread with specific chip requirements if I still cannot find what I am looking for, where I will compare my requirements to specifications that can be met with some of the devices people listed in this thread compared with my own sizing up of the classified datasheet ASIC.

This thread can just live as a re purposed (hijacked) warning (and useful guide) to those interested in the whole enchilada rather then just the algorithmic subsystem of a typical encryption system that I am interested in. I do feel that there is generally useful information here.

 I can't say the points are useless but they feel mostly irrelevant to my interests in the ASIC technology. I also have never seen a encryption system design/engineering/development thread on EEVBLOG before so there might have been superheated interest in the topic that caused this chaotic precipitation of information on the nucleation point that is this thread.

All right, I understand your frustration.  You came here asking about hardware encryption blocks and we did indeed branch out from that.

You're right that we shouldn't be discussing AES as encoding/decoding.  That was sloppy.

Answering the most basic question about how to get the AES encryption done in hardware:

• Get a microcontroller with an AES block built in
• You load up the key registers, load up one block of data in the input registers and hit the 'go' bit in the status register.  Some few clock cycles later, the 'done' flag goes up and your result is ready in the output data registers.
• For maximum throughput, you can use DMA to get the data in and out automatically rather than getting the CPU to handle everything.
• Flows of some 10s of Mbytes / sec can be piped through, e.g. a Cortex M4 @ 150 MHz.
• If you don't want all the fancy NDA NDA NDA tamper resistance, you can look for a more generic chip with an open datasheet.  Possible options are ST STM32, NXP LPC, TI Sitara, Silicon Labs Pearl Gecko / Jade Gecko, etc.  You'll have to open the datasheets to make sure the crypto part hasn't been chopped out into a supplementary datasheet under NDA.

But, I beg of you, please don't think that using AES is sufficient.  Please have a look at this very brief piece of Wikipedia article https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_(ECB), which I think makes a great example of how the block cipher is only a part of your crypto system.

Finally: did you ask Maxim for the datasheet (including NDA) of the MAXQ1061?  Seeing as they're billing it as an IoT chip, they may be willing to deal with you even if you aren't buying 10,000 pieces/year.

[coppercone2]

I did not bother to ask Maxim because my need is like, a few chips for a life time.

Just wanted to make a wired secured field telephone that runs on a thin cable. Maybe sell a few to some kinda electronically savvy friends who would never use it. Thought maybe make it a video phone. I kinda lost interest already. You would just run a wire and plug in the telephone when you got there and keep it with you when you leave. It's not meant to hit the postal service or something. I was hoping with a ASIC I could figure out how to make the interface using discrete logic with some kind of squelch (at least for the audio only one), with a hardware card for keys.

[xani]

Make up a random one-time pad and xor it with the data before you send it and give the microcontroller on the other end a copy of the same pad. The strongest most unbreakable crypto.

That works only when

• Message size <= key size
• you only use key once

So in other words extremely impractical

I did not bother to ask Maxim because my need is like, a few chips for a life time.

Just wanted to make a wired secured field telephone that runs on a thin cable. Maybe sell a few to some kinda electronically savvy friends who would never use it. Thought maybe make it a video phone. I kinda lost interest already. You would just run a wire and plug in the telephone when you got there and keep it with you when you leave. It's not meant to hit the postal service or something. I was hoping with a ASIC I could figure out how to make the interface using discrete logic with some kind of squelch (at least for the audio only one), with a hardware card for keys.

Get two Raspberry Pis and any voip thingy over openvpn if you just want to "make a thing".

If you really want to bother with micros, Silicon Labs ones are pretty cheap and have AES 128 engine on board with reasonable (IIRC 52 cycles per 128bit data block) speed

[coppercone2]

Just use an MCU or an FPGA. If you really have anything to hide that is worth the gov't or military to use their power to hack your system, then don't resist their fucking intent and bend over and take it.

I never felt some kind of like god like awe from any of them. And I would rather do business with a hydralisk to be honest.

[floobydust]

NXP has new Aug. 2018 A71CH security IC for IoT applications.