So it looks like the firmware uses SHA-1 with the cloud and that algorithm just got busted by some google researchers. I know on the local cloud that algorithm is used so I’m assuming the public cloud it’s used as well. What are the plans to migrate from SHA-1.
SHA-1 has been “considered insecure” for many years now but lots of systems are still using it in a legacy way. The Google result certainly moved the needle in terms of time to generate a collision but I don’t see how reporting a a wrong firmware checksum from a device can hurt much. Still it would be better to switch to a more modern hash function.
That’s a great question! The handshake does use SHA1 in a very specific way on fixed length, encrypted and signed messages. It would be extremely difficult to find two equal length blocks of data that have the same hash, typically collisions are easier to generate when you aren’t being strict on length checks. In the legacy handshake case the handshake does the following:
- server sends a random nonce to the device
- device adds its deviceID to the nonce, encrypts that with the server public key, and sends that back
- server decrypts this message, verifies it, looks up the device public key
- server generates a session id, encrypts it for the device (fixed length), uses sha to make a verifiable signature hash of this message, and then signs that hash.
- device decrypts session key using its private key, verifies the signature from the server, and kicks off the session
It would be very difficult to exploit sha1 in this case, because each component / message is an expected length, and the lengths are small, but we’ll be reviewing any uses of this hash and looking into next steps to make sure the handshake remains as secure as possible.
Newer devices / firmware (electron, etc) use updated crypto, but we want to make sure we support older devices and help them upgrade as well (old kickstarter cores, etc).
Awesome, we saw that here - https://github.com/Brewskey/spark-protocol/blob/dev/src/lib/Handshake.js#L332-L345
I don’t have much (any) experience working with crypto and we just wanted to make sure that there wasn’t any real danger in the Local Cloud code. We’ve updated the user password hasher to use a different algorithm.