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)
Well, 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.
There 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.
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.
There 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.
Not 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.
This 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.)
* We really care about on-the-"wire" efficiency. So we like having control over that.
* We actually looked very hard at DTLS, and do support it, but it is still optimized for browsers and not devices and as such carries some thought-baggage that is tricky to work around. So DTLS doesn't carry the bulk of our traffic.
* IPSec turned out to be impossible to support at the back end. Equipment that supports IPSec tunnel termination often is sold in terms of tens of thousands of tunnel terminations per box. We need tens of millions. That scale does not work for us. We do use it in some specific circumstances though.
* Anything that requires TCP is a non-starter as well. Not at all for the same reasons as the QUIC people. The NoTCP joke was really funny to me.
>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
I beg to differ. What's we've seen is non-stop problems from implementation mistakes when it comes to all of the extra extensions. Maybe this indicates there would be a market for an opinionated TLS embedded library...
>On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys.
Static keying issues aren't unique to IPsec, they occur with every symmetric cipher. There is nothing stopping you from having a management tool that rotates the static key based on a master key and the day. Or if you want to send updated keys, you just encrypt them and send them over the IPsec connection using GPG or whatever your asymmetric choice is.
>Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.)
I'm sorry for saying this, but that's what every single person that has implemented a broken protocol thinks. It's true that it's not hard to get one that encrypts and decrypts. The trick is getting one that doesn't leak any information. There is basically know way to know that without an extensive analysis by the entire crypto community.
Look at how long TLS has existed and they are still just finding issues now. RC4 is another example of one that looked pretty good for quite a while and then fell under scrutiny. Do you really think you are smart enough to know everything the entire crypto community knows?
It's really not true that most of TLS's problems are implementation-based. Problems that had nothing to do with implementation:
* CRIME, which conceptually breaks the way TLS wants to handle compression
* POET, which is an oracle attack against the way TLS does CBC
* BEAST, which exploits IV chaining in the TLS CBC construction
* The RC4 flaws break one of the most popular TLS ciphers, which was ill-advisedly included in SSL3/TLS
I could probably go on. For instance, the JSSE Bleichenbacher flaw looks like an implementation issue today, but it's an implementation that fails to perfectly implement a clumsy countermeasure TLS builds in to Bleichenbacher's P1v15 attack which TLS was originally totally susceptible to.
These aren't "implementation extensions"; this is core functionality.
Heartbleed was an implementation flaw. TLS's security record is much worse than just the implementation flaws. You're actually unlikely to experience lots of Heartbleed-like flaws implementing TLS in a safe language, and equally likely to have them implementing something different in C.
(I suspect it is both badly designed and easy to analyze, but I do wonder about the state of the alternative protocols)