4 ms·

Care 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 12y ago
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.
- hueving 11y ago
  So I suppose the obvious question is, why did you roll your own instead of a well-known VPN protocol?
  - tptacek 11y ago
    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.
    - JoachimSchipper 11y ago
      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.)
      - bdamm 11y ago
        These are all very good points. In addition: * 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.
      - 11y ago

bdamm 12y ago

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.

hueving 11y ago
So I suppose the obvious question is, why did you roll your own instead of a well-known VPN protocol?
- tptacek 11y ago
  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.
  - JoachimSchipper 11y ago
    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.)
    - bdamm 11y ago
      These are all very good points. In addition: * 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.
    - 11y ago