[Security] TLS Certificates Verification

Eric Rescorla ekr at rtfm.com
Tue Aug 19 12:33:53 CDT 2008

On Tue, Aug 19, 2008 at 10:23 AM, Dirk Meyer <dmeyer at tzi.de> wrote:
> Jonathan Schleifer wrote:
>> "Eric Rescorla" <ekr at rtfm.com> 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.


[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.

More information about the Security mailing list