On Tue, Aug 19, 2008 at 10:23 AM, Dirk Meyer <[EMAIL PROTECTED]> wrote: > Jonathan Schleifer wrote: >> "Eric Rescorla" <[EMAIL PROTECTED]> wrote: >> >>> Why is it desirable to use an SAS here? A short, secret key printed >>> on the top of the STB seems much more convenient. >> >> Uhm, isn't SAS more or less like a short secret key? If you verify an >> SAS or a short fingerprint (but fingerprints are never short!), where >> is the difference? > > The difference is that ESessions require the same secret on both > sides. How can to set-top boxes with different keys printed on them > talk to each other? They need help from something else. > > I do NOT want to role out SAS. If we use TLS with self-signed keys we > still need a way to verify that key. With SAS you can create a secure > connection between two clients. > > 1. Set-top box 1 connects to my PC. They exchange TLS keys that are > not verified. Now I type in the secret printed on the box on my > PC. They open another secure link on top of the TLS link using > SAS. Now they exchange the TLS keys over that link and know that > the TLS keys are correct. My PC signs the key of the set-top box > and they disconnect. > > 2. Set-top box 2 connects to my PC and they do the same > > 3. Set-top box 1 connects to set-top box 2. Both see that the TLS key > is signed by my PC which they trust. No SAS needed.
Actually, this is a lot more complicated than it has to be. TLS has two features that make this trivial to do and that don't rely on certificates 1. A PAKE mode (SRP)[0] 2. Session resumption. SRP allows the client and server to establish an authenticated connection based purely on a short password. The only restriction is that they need to share a known DH group, but that's easy to profile. Once that connection is established, TLS session resumption can be used to establish new keys between the communicating peers without any use of public key cryptography at all. All that's required is that there be long-term secret storage on both sides for the session cache. (Actually, this is only strictly necessary on the client because of CSSC [RFC 5077]) If you're not willing to have long-term secret storage (though why you would be willing to have long-term public storage but not secret storage would need some explaining) you can do TLS-SRP and then rehandshake on the same TLS channel, this time using self-signed certs, and then the peers can simply remember each others certs. Note the real advantage of both of these approaches that you don't need any kind of readout on the STB. Because the secret is static, it can be done with a sticker on top. By contrast, SAS schemes require both sides to have a display. -Ekr [0] For the record, SRP has some potential IPR issues associated with it. See the very extensive discussion on the TLS mailing list, but the executive summary is that it's not *clearly* unencumbered, but not clearly encumbered either, because of some original patents on the concept which may or may not cover this variant. If you're willing to live with active-only dictionary attacks on the first connection, you can use TLS-PSK, which has no known IPR issues.
