Crypto Chips, please explain

[jnz]

• Have a wireless device that will get a connection to my server
• Mix of secure (SSL) and insecure (SPI/UART) transits
• Want to make sure that any "commands" the device receives are verified to be legit (asymmetric)
• Want to encrypt firmware so that I can update but keep the code as secret as possible (asymmetric or AES)
• I am FULLY aware that the device host ARM M4 could be decapped and code ripped, want a secure system even if the firmware is ripped
• Planning on partially using the ARM's unique ID to factor in to security

A friend recommended we looked at Atmel Crypto Chips (http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx) and I'm fundamentally not understanding some things.

It seems the crypto chips are great at storing values, I could come up with these at manufacturing, like an agreed upon random key, or "lock" in our private key, or whatever. But it seems every way I conceive them to work is insecure.

1. If I send in an encrypted packet over serial, and the cryptochip evaluates it to match some locked memory, is the only way it can "tell" my ARM chip that it's legit is with an OK command right? So my ARM chip could be fooled with any mod that just replied OK anytime it's waiting for a response from crypto right? Seems very insecure.

2. If in the ARM, I generate a "challenge" that only my server can authenticate, at some point if I roll the crypto chip in, I'm still waiting for an "OK" response right?

3. The only way I see this working is with asymmetric! Where the crypto chip uses it's private key, to roll me a new public key. Which the server could use it's matching private key to authenticate, but how does this help me with encrypting the actual data!? If I have a "command packet" and a "public key sig packet", don't I still wind up either needing the private key on the ARM (which is insecure) or am I in another instance waiting for crypto chip to send OK when it's verified?

4. Is the answer #3 but I have to use that public key to further encrypt the whole packet? So if I have (SERIAL + COMMAND + LEN + DATA) I need to send all that into the crypto and have it roll that data into something only the server can verify? Because if that's the case, then that packet of serial+cmd+len+data will be unencrypted over serial (which I can live with I guess)... But this means that my crypto chip could be taken and put on a cloned/malicious ARM yea? That seems bad too.

It seems with my very lacking understanding of encryption that having an external cryptochip is not really providing me much security here. Can someone explain simply?

[ade]

The "OK" challenge response is not a simple "OK" but a cryptographic response.  It is a value that can only be computed based on a shared secret key known only to your ARM chip and the Atmel chip, using an algorithm known as HMAC.  "Any mod" can't fool your ARM because it cannot compute the correct cryptographic response (since it doesn't know the shared secret).

Public-key cryptography is not typically used to directly encrypt data.  It is used for authentication.  To send data, you generally generate a new random shared key between the sender and receiver -- perhaps using techniques such as Diffie-Hellman -- then encrypt the data using regular symmetric encryption (e.g., AES) with this new shared key.

It's great that you're learning this stuff, but I'm going to be a little frank... if this is for something important, then seek help from specialist security professionals (and I don't mean just some random dude with a CISSP).  In my line of work I've seen many, many, many broken/insecure security protocols designed by very smart people.

[jboard146]

The first ting that comes to my mind it use some sort of cheep SBC running Linux/FreeBSD. Typically "rolling your own encryption" is going to be inherently insecure. Use proven secure encryption libraries and strong keys. I'd say use OpenSSL, but is is it has it's own issues. The plus side, when another vulnerability is found using something running linxu/freebsd you can get a "fixed" version of the library.

Yeah, almost all bets are off when you have physical access to the device. Realistically if they want in they will get in. All you want to do is create the cost of entry greater than the value of data you are protecting.

If you are going cheep as a hobby project I'd just get two Raspberry Pi's. If this needs to be a commercial/industrial product, pick a vendor who has long term support for their hardware.

[stmdude]

For a quick primer into how to break "secured" devices, I'd recommend Bunnies book about how he hacked the original XBox. It's free now, so you have nothing to loose.
http://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf

It covers HMAC, sniffing busses, etc.

[jboard146]

Yes, that is a very good read. Highly recommended.
His book is free because he dedicated to the honor of Aaron Swartz.

[jnz]

The "OK" challenge response is not a simple "OK" but a cryptographic response. It is a value that can only be computed based on a shared secret key known only to your ARM chip and the Atmel chip, using an algorithm known as HMAC.  "Any mod" can't fool your ARM because it cannot compute the correct cryptographic response (since it doesn't know the shared secret).

One quick issue! AT NO POINT do I want the ARM chip to necessarily have any permanent keys. The whole point of the cryptochip is to keep the private key unreadable. The ARM can be ripped. I want the only "readable" copy of the private key to be on our server, unreadable copy on the cryptochip.

Yea, I thought about this, and figured the answer must be a return crypto response. But not sure how that's any more secure as I'm trading my now AES key around then (remember, I don't want to keep a shared copy on the ARM). The fundamental thing I'm not getting is how this works on an external processor via open serial connection. At some point, it seems I need to expose my key, or expose my data if the keys don't exist on the ARM and are only on the cryptochip.

I have a feeling the compromise is to generate a pre-shared key set between my server and device at time of production, but.... Then what am I using the cryptochip for. I know there is something I'm not getting.

Public-key cryptography is not typically used to directly encrypt data.  It is used for authentication.  To send data, you generally generate a new random shared key between the sender and receiver -- perhaps using techniques such as Diffie-Hellman -- then encrypt the data using regular symmetric encryption (e.g., AES) with this new shared key.

I looked into D-H... I'm kinda skeptical that's what I want in this case as it's entirely arbitrary in implementation it seems, arbitrary means weak in my case. EDIT: There is an ECDH implementation on one of their chips - that's the part I want it seems. I have to figure there is a better way to sign as well as encrypt with these chips, standards that I'm clearly supposed to be using.

It's great that you're learning this stuff, but I'm going to be a little frank... if this is for something important, then seek help from specialist security professionals (and I don't mean just some random dude with a CISSP).  In my line of work I've seen many, many, many broken/insecure security protocols designed by very smart people.

Well thanks mom But I'm working this out for me. It's either I put in something I like in this project, or nothing goes in at all. It's not nation state important. I'm just trying to do the best job I can now, so I don't need to go back to it later. Literally, the only thing I have in my code that's important is a stack we're licensing. All the same... Do it right, do it once.

[jnz]

For a quick primer into how to break "secured" devices, I'd recommend Bunnies book about how he hacked the original XBox. It's free now, so you have nothing to loose.
http://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf

It covers HMAC, sniffing busses, etc.

I'll make sure to not use the famously weak TEA encryption. Problem solved!

[Bud]

1. If I send in an encrypted packet over serial, and the cryptochip evaluates it to match some locked memory, is the only way it can "tell" my ARM chip that it's legit is with an OK command right? So my ARM chip could be fooled with any mod that just replied OK anytime it's waiting for a response from crypto right? Seems very insecure.

I think you could also craft packets for negative acknowledgement, i.e. the correct response for which would be NO. The "bad guy" would not know to which packets YES or NO is expected. Your ARM would then branch off accordingly.

[ade]

 No, no, no.

Honestly, unless there is a legal or contractual obligation to encrypt the 3rd party stack, don't bother.  With almost certainty whatever you will design on your own will not be secure, will just cause complications for your product, and is simply a waste of your time.

[jnz]

No, no, no.

Honestly, unless there is a legal or contractual obligation to encrypt the 3rd party stack, don't bother.  With almost certainty whatever you will design on your own will not be secure, will just cause complications for your product, and is simply a waste of your time.

That's not an answer, nor is it the type of advice that should be preserved on a forum.

Let's say there is a legal obligation to make an attempt. That should make your "well, if you aren't the world's greatest cryptographer - don't bother!" standard irrelevant.

1. Server posts it's public key, device gets it and can pack all sorts of things only the device knows and send to server. Easy! The private key on the server stays there.

2. Now, when the device needs to decrypt... This is the issue!

• If I store the device's private key in ROM, it's vulnerable to decapping and other methods, let's say any side channel attack
• If I use a crypto chip above... My device can ask the chip for a new public key to use, I can send that to server, server could encrypt a packet for the device
• BUT when the server responds with encrypted info, I only have two options: To ask for the private key the crypto chip used (which exposed the key used, dumb), or send in the encrypted packet in and get the decrypted data out (now my data is exposed, also stupid)

So why is it no one can explain how these crypto chips actually make the device side secure? Even if I wasn't talking asymetric and was just talking AES... I either have to store my key in device ROM or I will be in some scenario where I'm exposing my key or data when it "comes back" from the cryptochip.

The best scenario I've come up with so far is a RAM stored random device key that the device comes up with when it sends the first encrypted packet to server using it's public key. I'd come up with 0x11223344, encrypt so only the server could see, then the server would just use that random key for that session (so basically a Session ID) - BUT - this removes any reason I'd use a cryptochip.... So what are they for !?

[Kilrah]

Any use for which your desire of not storing a shared key on the main processor would not be considered reasonable/necessary?
I doubt many go to the length of expecting people to start physically having a go at the die (i.e. expensive). If it's worth doing that much then there are other solutions like special "secure" processors with on-chip hardware methods, or things like storing the key in battery-backed RAM with tamper detection methods that wipe it way before you physically get to the chip let alone start decapping it. See Dave's video about the card payment terminal teardown.

[ruffy91]

So what do you want exactly? Confidentiality, integrity, authentication? All of it?
For your question: The server will send you a message and the HMAC (cryptographic hash) of the message. You then send the message to your crypto chip and compare the HMAC you get from your crypto chip with the one you got from your server. If they match you know that the server has the key that's also in your chip.

[ade]

That's not an answer, nor is it the type of advice that should be preserved on a forum.

Hi jnz, again it's great that you want to learn and there are lots of people in this forum (me included) who will gladly help.

But, if you see a newbie in the beginners forum playing with mains voltage while asking basic electronics questions like ohms law and confusing voltage vs current -- at what point do you say stop, stop, stop, hire an electrician?!!!!   It's a disaster waiting to happen! 

No offense but you're at the level that you know "just enough to be dangerous", and you're apparently designing something for work.  Honestly any security professional would look at this thread and say, "yup, I've seen this movie before, and the ending isn't pretty!"

So why is it no one can explain how these crypto chips actually make the device side secure?

Because there is no single answer.  It all depends on your threat model and your security assumptions.  And there is no answer because these chips are primarily meant for authentication.  That's only one of the C-I-A triad.  They cannot protect all possible attack scenarios, in particular they cannot protect the scenario where your ARM chip is compromised.  I'm not talking about de-capping, but if an adversary can replace your ARM chip with a malicious chip.

[jnz]

I doubt many go to the length of expecting people to start physically having a go at the die (i.e. expensive). If it's worth doing

Agreed! But, cheaper all the time. And that doesn't consider chip specific exploits, or side channel attacks. Let's just say that I'm extremely cautious of "trusting" my firmware entirely. If I can store something on the server, I'm going to.

No offense but you're at the level that you know "just enough to be dangerous", and you're apparently designing something for work.  Honestly any security professional would look at this thread and say, "yup, I've seen this movie before, and the ending isn't pretty!"

I get that, and don't necessarily disagree. But that doesn't change anything. I'm not hiring out an encryption scheme because it's VERY unlikely to even be attempted to circumvent - that said - it's not expensive to put SOMETHING up so I will do that.

in particular they cannot protect the scenario where your ARM chip is compromised.  I'm not talking about de-capping, but if an adversary can replace your ARM chip with a malicious chip.

Now we're getting somewhere! That's exactly one of things I'm coming around to. That if you can trust the ARM chip, it's a whole different game. And for protecting peripherals you can make assumptions about legitimacy (ie: Loading a basic "certificate" on the accessory's cryptochip and verifying on the host micro or over the air). Data Encryption aside - My device IS an accessory (kinda) but even if I treated it this way, I think there would be a vulnerability on the server side if a malicious device were to try and pull data. So, yea, I get it's complicated and there is no one answer - but you did a fair job with the quote above.

The whole concept of ATSHA2xx is based on your ARM or FPGA will never be compromised. It assumes a secure host environment with possible fake peripherals.
It is mainly designed for 2 purposes: a. to prevent fake peripherals (i.e. aftermarket cartridges), and b. FPGA protection (FPGA will not work if response from auth IC is not equal to internally generated one).
If the logic of FPGA or code of ARM can be reverse engineered and modified, the whole concept will not work.

That makes sense! As I wrote above, my device could be considered an accessory, but it's also got enough power and ability to just work with the server on a key trading scheme. Using one of these chips in a place where you don't have a micro at all (over i2c or 1-wire) makes sense to protect an accessory. I definitely get that. The FPGA stuff is less solid to me because I've never used one, but I think I get the idea just the same.


So.... my theory isn't wrong. That if you have an external cryptochip, you have to expose data or a key, or rely on an easily defeatable  YES / NO. But... for the application these are used in, you have to assume a matching cert or key on a secure processor. It doesn't sound like I want one of these, but I'm really glad I asked the question and really appreciate all the answers!

[ade]

it's not expensive to put SOMETHING up so I will do that.

That's very different than "do it right, do it once".

I won't argue not to increase security... but, implementing a security scheme always has non-trivial costs. 

It's not just the upfront and ongoing design / implementation / testing costs... everything you do for the life of the product gets incrementally more complicated.   E.g., when the product misbehaves you need to spend time debugging to see if the security scheme interfered with the proper operation of the product.   If a device in the field fails, then you may not be able to just replace it, but you may need procedures to generate new device keys, use an out-of-band mechanism to transfer certificates, make sure security provisioning on the server gets updated, make sure the old credentials are revoked (and have a method to check against the revoked lists), etc. 

Then, a year after product launch, all your clients are screaming at you because all those individual on-chip internal certificates have expired and there's no automated procedure to update them.  Or someday the security chip vendor goes on a long backorder and your production run gets delayed. 

These seemingly small incremental costs all add up.  They have to be balanced against the risk and liability of not protecting the device.   If the risk/liability and probability of attack occurrence are all low, sometimes doing NOTHING is better than doing SOMETHING.

Companies often put in small security measures (or even just the appearance of security measures) to deter the most casual attackers.   We call this "security theater".  That may be fine too, and goes back to what is the threat model and what are the underlying assumptions.   

[Kjelt]

I agree with ade, this is not something to take lightly.
There is no security holy grail that has no leaks, every system ever designed has weaknesses.
You want and have to find the right balance between how much you want to invest to prevent an security incident and the costs.

As you will see in the pictures below, your requirements puts you completely in the ultra high costs ultra high security requirements, I only know banks with smartcards/paying terminals and that kind of businesses that want to put out that much cash to realize.

If you say you don't want to store a secret key inside your Arm device then you already have so many other problems to figure out:
 - how will the server authenticate your device
 - how will the Arm uC authenticate the external crypto chip
 - how will you prevent a hacker to simpley sniff the communication between the uC and the external crypto chip
I can name tens of these you have to figure out, I talked a lot with the external crypto chip guys and none have a solid answer without a shared secret key between the uC and the crypto chip, think about that.

If you have a requirement like

"I am FULLY aware that the device host ARM M4 could be decapped and code ripped, want a secure system even if the firmware is ripped"

that means you need a uC that can execute encrypted firmware with a unique key (not firmware unique but absolute unique per device), which means that any single device gets his own unique firmware(update), think about the logistics here. So ask you questions, do your homework but realize that playing ball in this league takes years of learning and experience and even then you make mistakes because you just think like one persone with one mindset and another person thinks differently and finds ways around that.

[Kjelt]

There are chips allow the use of encrypted internal or external code storage, with a deep buried and fragile key eFUSE on die.

Yes indeed there are (more expensive) security microcontrollers that can execute encrypted firmware, and have lots of other security measurements like a tamper mesh with sensors that will instantly delete the secret keys if someone is trying to physically access the device etc. etc.
BUT they are relatively expensive and with your future roadmap/platform are limited to that single supplier (monopoly). As said before it is all a balance between securitylevel and costs and most companies I know of concentrate on the latter.

[apelly]

Well thanks mom

That attitude. Right there. 

[jnz]

Then, a year after product launch, all your clients are screaming at you because all those individual on-chip internal certificates have expired

lol, I'd have to be out of my damn mind to put timed certs in! That would definitely never happen. 

I can name tens of these you have to figure out, I talked a lot with the external crypto chip guys and none have a solid answer without a shared secret key between the uC and the crypto chip, think about that.

that means you need a uC that can execute encrypted firmware with a unique key (not firmware unique but absolute unique per device), which means that any single device gets his own unique firmware(update), think about the logistics here.

Exactly, this ENTIRE POST was about how an external cryptochip works when you either seemingly have to give up the key or the data. I had just assumed I was missing something with how these work. But it seems you either have to give up the key, the data, or suffer with an easy "OK / NOT OK" response unless you want to also have a matching key in your ROM. If you have a matching key in your ROM, and you want a faster way to off-load ECC or even AES, the cheap external chip doesn't seem that bad - but - it's a whole extra device that needs programming at manufacturing or one first run.

Yea... I'm not getting what is so difficult about taking the firmware stored on the server, wrapping it that device's key on demand and transferring it to the device. Since this device can only work with a connection to the server, I'm not scared of this.

There are chips allow the use of encrypted internal or external code storage, with a deep buried and fragile key eFUSE on die.

Yes, but not in the package, price, feature-set I'll need. I may make use of OTP programming during mfg, but maybe not.

That attitude. Right there. 

So, what you're saying is you don't have anything to add on how cryptochips work? Because I think we've covered it now, way after Ade made his comment that did not even remotely answer the question but instead posed only a warning - later did follow up with a reasonable explanation that I'm not really missing anything when it comes to these external chips. When you're done on your horse, come down and try some context?

[link47]

So why is it no one can explain how these crypto chips actually make the device side secure? Even if I wasn't talking asymetric and was just talking AES... I either have to store my key in device ROM or I will be in some scenario where I'm exposing my key or data when it "comes back" from the cryptochip.

The best scenario I've come up with so far is a RAM stored random device key that the device comes up with when it sends the first encrypted packet to server using it's public key. I'd come up with 0x11223344, encrypt so only the server could see, then the server would just use that random key for that session (so basically a Session ID) - BUT - this removes any reason I'd use a cryptochip.... So what are they for !?

I work in an industry where I have used these devices on a large scale. If you want to authenticate a piece of equipment (ie, verify the equipment belongs to you while it is being used in the field), you could embed the secure device, say the ATSHA204 into your product so that removing it would be extremely difficult without damaging the component (potting/epoxy etc). These Crypto devices typically have fuses that are burned in with the key, and are tamper resistant.

The encrypted flash on your microcontroller stores the key and sends a series of commands across a 1 wire interface (Atmel calls this the challenge) based on the key and hash algo. This can and should be randomized; most use a time and date stamp that plugs into the SHA. The random message that comes back from the device is then compared against your microcontroller's calculation.

So, to answer your question, the 1-wire communication is difficult to trace, the messages sent back and forth on the line are random, the client side chip is impossible to read physically, and the server side (your micro's flash), with proper encryption, will be extremely difficult to read.

[ade]

lol, I'd have to be out of my damn mind to put timed certs in! That would definitely never happen. 

Easy for you to say the above now... but all the bright engineers, testers, software developers, architects & security gurus from all of these companies completely missed it:

On Dec. 7, 2014, certain older model payment terminals made by Hypercom stopped working due to the expiration of a cryptographic certificate used in the devices...  (the company) is now working with customers, distributors and channel partners to replace the certificate to return terminals to an operational state.

http://krebsonsecurity.com/2014/12/security-by-antiquity-bricks-payment-terminals/

Wink smart home hub goes stupid in security certificate snafu.  Wink, the maker of a smart home system designed to control lights and other electrical devices from an app, has suspended all retail sales of its $50 central Hub while it works through a glitch that bricked many of the Hubs on Saturday.

http://www.geekwire.com/2015/wink-smart-home-hub-goes-stupid-in-security-certificate-snafu/

Sysadmins with older Juniper Networks kit have been left scrambling to keep their networks running after a security certificate expiration bricked their boxen. ... Users of EOL kit like J2300 and J4300 routers discovered that Juniper Networks used a hard-coded X.509 cryptographic certificate in the systems – and that cert, which is used to securely connect to Juniper to check the customer's software licence for the router is up to date, has now expired.

http://www.theregister.co.uk/2014/03/31/cert_fail_bricks_old_juniper_kit/

These were all costly mistakes with significant monetary and/or reputational damages.  Those Hypercom terminals were deployed by major retailers world-wide.  The outage probably cost them over $1 million.  Another set of their POS devices got bricked again last year due to another batch of certs expiring.  They are still dealing with the fallout today.

Wink reputation was so damaged that the company went bankrupt later in the year, and was sold off to Flex.

Many Juniper customers with those EOL routers probably decided to replace them with competitor products.

p.s. A non-expiring certificate is also security issue.

[apelly]

So, what you're saying is you don't have anything to add on how cryptochips work?

No. I'm saying you can't invent your own implementation because it will be weak. The original advice to seek an expert was sound. If you don't want to do that then at least ask on a crypto forum before you do anything.

Of course if you're just having an idle chat about it, that's different.

Who is your adversary?

[Kjelt]

Exactly, this ENTIRE POST was about how an external cryptochip works when you either seemingly have to give up the key or the data. I had just assumed I was missing something with how these work. But it seems you either have to give up the key, the data, or suffer with an easy "OK / NOT OK" response unless you want to also have a matching key in your ROM. If you have a matching key in your ROM, and you want a faster way to off-load ECC or even AES, the cheap external chip doesn't seem that bad - but - it's a whole extra device that needs programming at manufacturing or one first run.

Yes this is why it is not so usefull to have such an external chip, the weakest link remains in the firmware of the uC. You do have now external chips that can do the entire TLS communication for the uC that works as a transparent throughput device (LAN in -> uC -> ext. chip -> uC-> LAN etc.) till the handshake is done and there is a session established, but then in the record layer one way or the other you need to do some processing on the data. So how do you get the data that is in the clear in the ext. chip in a secure way back to the uC?
Again, using encryption with some sort of PSK which resides inside the firmware. So left or right if you have an external security chip you need a PSK in firmware.
So unless these interesting secure pieces of silicon starts to be integrated inside a uC , they are not of that much use in my opinion.

Yea... I'm not getting what is so difficult about taking the firmware stored on the server, wrapping it that device's key on demand and transferring it to the device. Since this device can only work with a connection to the server, I'm not scared of this.

Please explain the details. You want a secure firmware update? Or the server providing the program data that the uC has to execute?
One way or the other the server (and uC) needs to trust eachother. One way or the other security always relies on a pre shared key (PSK) being a symmetric PSK (for AES for instance) or a private and public key (could also be in a certificate). So if those are not stored in the firmware, and the external device has the same chicken egg problem (see above), you have a dilemma.
You could leave some critical part of the calculation out of the firmware and let the server do that, just as we had the dongles with the expensive PC software calculating some stuff, without dongle the cloned software would be useless. Still far fetched and critical dependency on the server connection.

I would suggest to accept some sort of PSK in the firmware, and concentrate on how to hide or obfuscate it, best using something that can not be copied/cloned. I am not going to share some of my own trade secrets but if you read the datasheets of some uC's and think about what makes two uC's different from eachother you can come up with something interesting yourself.

[ade]

You could leave some critical part of the calculation out of the firmware and let the server do that, just as we had the dongles with the expensive PC software calculating some stuff, without dongle the cloned software would be useless.

The security model is slightly different with a dongle, because that's something the attacker must have (and so in itself is a form of authentication).

With computation moved to a central server, that's not something the attacker must have.  So if the attacker can reverse engineer the ARM chip's firmware, then it's over.   Even if the security protocol works in part by reading some device UUID that's unique to each individual chip, the attacker can simply write custom firmware to read the value from one valid chip, then make lots of copies using that value.  (Ignoring for a moment other defenses against overwriting firmwares, etc.)

We see this kind of attack a lot with apps on jailbroken iOS devices (or rooted Android devices) and other DRM schemes which depend on server authentication.   Actually this is where the Atmel chip can help, by essentially substituting the dongle and providing a challenge-response authentication platform where the secret keys cannot be read back out.

[Kjelt]

True, but then the authentication of the device should be without any "knowledge" or active interaction of the host uC. The external crypto chip is then the actual authenticating device.

BRW, the cloning of the firmware and spoofing the uuid will not work if the server blacklists that uuid. Which it will if more then one device with different ip adresses contact it. So the attacker should then use another uuid which is on the whitelist from an ip address and password matching  to the server. Not worth it.

[ade]

BRW, the cloning of the firmware and spoofing the uuid will not work if the server blacklists that uuid. Which it will if more then one device with different ip adresses contact it.

Easily defeated by providing a proxy / gateway server.  Then we get into rate detection which gets defeated by caching.  Etc.

[jnz]

BRW, the cloning of the firmware and spoofing the uuid will not work if the server blacklists that uuid. Which it will if more then one device with different ip adresses contact it.

Easily defeated by providing a proxy / gateway server.  Then we get into rate detection which gets defeated by caching.  Etc.

Gateway is kind of an interesting idea, but ultimately easily detectable. I'd see any amount of abuse on the server side. If one chip was hooked to a machine so as to legit access the server then pass on data for a different series of devices, I'd see too high of usage on that serial, a cool-down for important functions (ones a legit user would only need once or twice anyhow) would fix this at least in a way it wouldn't be profitable to abuse our server. I really think we're in a whole different level of hacker at this point.

Interestingly, same goes for if someone DID hack my ROM. All they would really get is a way to feed my server data (ask my server's public key and be able to package the right data to it, but then all they've done is exactly what the original does), but again, I have all sorts of monitoring and ability to blacklist on the server, plus I'd only ever give the answers to a device, not the equation to generate them.

Honestly I was a little apprehensive about moving my product to an online interface, but now, I just don't see any other secure way (that I can afford).

The interesting theme of this thread is really: How much do you trust your chip? Some of you guys think decapping and side channel attacks are more difficult than they are. $5,000-$10,000 to pull my stack that will have cost $20,000 is a pretty great deal I think.

[jnz]

On the topic of Cryptochips.... Having a pre-shared private key that the cryptochip and server agree on, that makes sense. If the chip and server agree on a private key from the start. Instead of getting the public key from the server AFTER making contact online, I could just generate one locally and it doesn't matter it's sent over 1-wire or I2C to the chip, package my data the device can't decrypt then connect to the server that can... 1/2 dozen of one and 6 of the other I think... I'm not sure when I'd want to do that except if I had a system that DIDN'T have live bi-directional access. Like if I wanted to securely encrypt a packet that was going on a USB stick or email and not talking to a live server.

If I can talk to a live server, I'll just ask for the public key. Only if I couldn't "talk" to the server right now do I see a reason to use a cryptochip in this fashion to generate a public key. This would be very secure for an offline device, but only one that will eventually transmit to an online device or a known-secure ROM that could store the matching private key.

[ade]

I'd see too high of usage on that serial, a cool-down for important functions

That's what I meant by rate detection (which would be on your server's end), but unless there are additional defenses this is often defeated by caching schemes (on the attacker end).  And so on and so forth with measures and counter-measures.

If the chip and server agree on a private key from the start. Instead of getting the public key from the server AFTER making contact online, I could just generate one locally and it doesn't matter it's sent over 1-wire or I2C to the chip, package my data the device can't decrypt then connect to the server that can

I don't quite get what you're trying to do there -- generating local keys, etc., -- but at first glance, doesn't seem very secure.

PSK used for something like challenge-response auth may be ok depending on how its implemented.  However they come with a ton of headaches as well.  I mean, the whole field of public-key cryptography largely exists to address shortcomings of shared keys in symmetric ciphers...

[jnz]

PSK used for something like challenge-response auth may be ok depending on how its implemented.  However they come with a ton of headaches as well.  I mean, the whole field of public-key cryptography largely exists to address shortcomings of shared keys in symmetric ciphers...

I wonder, is there a term for using asymmetric keys (private/public) but also where the private is pre-shared on both ends? When I usually think about private, I always figure that private exists in one place only. This obviously is 1/2 as secure as there are two vulnerable locations, but forgetting about that for a moment...

Is that just considered "asymmetric pre-shared private key"?

[ade]

A private key should never be shared between two communicating parties (e.g., between a server and a device).   If the two parties need to authenticate each other, then they should hold each other's public keys.

If you have full control over all the servers and all the devices at all times, then exchanging public keys is fairly straightforward.  Otherwise, things get complex very quick -- you'll basically need public key infrastructure (PKI) with certificate authorities, etc.  Then the trust-relationship is based on mutual trust of the certificate authority.  Each device/server will have a signed certificate instead of a simple public key.

[Kjelt]

Indeed the easiest is to think about PSK (pre shared key) always as symetric cryptography, eg two (or more) parties share the same secret key, if this key is compromised it is over. Sidenote: to prevent this as much as possible you should always use a secure keyderivation scheme in any protocol instead of the real key. Try not to use the term private key in these schemes, but secret key, otherwise it will confuse everyone 

And there is a-symetric cryptography where each party holds a key-pair! One is the secret key which now should be called the private key, and the other is the public key which is no secret and can and should be shared with other parties to communicate.
For authentication: the only way another party really can know that the other party is who he says he is in this case is if another (trusted third) party vouches that that public key is from who he says he is.
And that is where certificates come in, in the simplest form a certificate is a digitally signed public key with some metadata.
However if that trusted third party becomes compromised the whole scheme falls apart. Or when the private key somehow is leaked, anyone can then also pretend to be that party.

[link47]

More on this topic is in the attached app note

Also found here
http://www.atmel.com/Images/doc8666.pdf

[ade]

Good summary link47.  Note all the models are for authentication only.