Crypto Chips, please explain

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