4 ms·
Do we know that the alternative protocols are better? Are we finding so many problems because the protocol was badly designed, or are we finding them because a
by justinsb 11y ago
Do we know that the alternative protocols are better? Are we finding so many problems because the protocol was badly designed, or are we finding them because an open protocol is much easier to analyze?
(I suspect it is both badly designed and easy to analyze, but I do wonder about the state of the alternative protocols)
- bdamm 11y agoWell, I work for a smart grid vendor (SSNI) and I know for a fact that our protocols are better. We actually use strong primitives, for starters. I can't understand why they rolled their own MAC, when robust and tiny implementations are rather plentiful. That just seems like a foolish waste of time, frankly. An ATMega can do HMAC-SHA256 for crying out loud. There is no excuse.
- newman314 11y agoCare to go into more detail how your protocols are better? It would be an interesting exercise to compare and contrast what you do differently than OSGP.
- bdamm 11y agoThere are several layers, for starters, each with its own protected session keys. At each layer, and after derivation (this paper was specifically about recovery of the MAC key so I'll not mention anything else) there are two symmetric keys, one for encryption (AES256, in a number of modes) and HMAC (HMAC-SHA256). Session keys are comparatively short lived, with a life span normally measured in weeks. The OSGP analysis has attacks on key generation, known-plaintext in padding, and an attack on the OMA digest itself. These don't apply to our protocols because (a) we use a much stronger and standard key generation sequence and (b) HMAC-SHA256 isn't vulnerable to padding attacks (directly) or the reversibility attack. All that said, I will never claim that we have a perfect implementation, but our devices are field upgradable, they do get upgraded, and we have quite a bit of attention on attacking our devices already. Our customers have been pen testing us for years.
- hueving 11y agoSo I suppose the obvious question is, why did you roll your own instead of a well-known VPN protocol?
- tptacek 11y agoNot the OP, but also can speak for the perspective of some vendors other than Silver Springs (I'm unfamiliar with Silver Springs protocol): 1. Running on an RTOS platform, not Linux, so no VPN builds cleanly 2. Running on constrained platforms for which code space is not available for all the crap that comes with a VPN codebase 3. Operating a very constrained RF protocol in which every bit in every transmitted frame has to be accounted for, so not only is there no room to run something like L2TP/IPSEC, but what crypto can be run is also compromised (this is what makes me worry about "we use strong primitives unlike OSGP"). 4. Operating simple protocols with simple service models in which lots of round trips for session establishment are unworkable. 5. Can potentially get AES working on the platform, but less reasonable to use anything that requires bignum math, which makes Diffie-Hellman a problem; instead just using static keys, or some simple key rotation schedule.
- JoachimSchipper 11y agoThis is true. Also, as someone who also works on network crypto boxes: the main VPN protocols are _really_ nasty. - OpenVPN requires TLS (you really don't want to use static keying in OpenVPN), which is a total nonstarter: the TLS protocol itself has non-stop problems, is completely infeasible to implement from scratch, and does not have any implementations useful for a high-security embedded device. Also, the data channel protocol is ugly. - DTLS-based VPNs are, well, DTLS-based (worse protocol than TLS, and still infeasible to implement). - IPsec is comparatively sane if you limit yourself to statically-keyed tunnel-mode ESP with no internal NAT'ing (NAT-T is ok, though). IKE is a pain (and usually requires certificates, which are very hard to parse correctly), and supporting all the zillions of options is extremely expensive. On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys. Also, IPsec overhead usually ends up being rather high in practice, and e.g. IPsec/L2TP is even worse. - In practice, anything that requires connection negotiation requires some surgery to support high-packet-loss scenarios. (Loss-tolerant protocols over statically keyed IPsec work decently well at packet loss rates that break most IKE implementations.) Also, for any given device, you'd usually prefer to support as few algorithms as possible and/or tailor choose crypto primitives that are well-supported on your hardware. Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.)
- tptacek 11y agoThere are AVRs that can reasonably "do" SHA2, but many have text size limitations, which motivates vendors to minimize the number of primitives they use (for instance, it might lead someone to use CBC-MAC instead of HMAC). Also: however capable your hardware is, if you're doing long-range RF (and not GSM), you've got a much more significant space and round-trip constraint to deal with.
- bdamm 11y agoCMAC is fine too if done properly. And RF constraints is no excuse for a weak MAC.
- tptacek 11y agoCBC-MAC is really not fine. :) In any case, just making a descriptive comment, not a normative one. Broken crypto is broken crypto, I agree. I just have a little bit of exposure to this particular design challenge, and those are two reasons I see people not using "best practices" simple cryptography in these kinds of applications.