Re: [TLS] Private Key Security [Was Re: DHE key derivation]
mrex@sap.com (Martin Rex) Mon, 30 September 2013 18:00 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B45621F9A59 for <tls@ietfa.amsl.com>; Mon, 30 Sep 2013 11:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.18
X-Spam-Level:
X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSFXcfa6h4bw for <tls@ietfa.amsl.com>; Mon, 30 Sep 2013 11:00:12 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9B14A21F9A3B for <tls@ietf.org>; Mon, 30 Sep 2013 11:00:11 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8UI07r8002228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Sep 2013 20:00:07 +0200 (MEST)
In-Reply-To: <52486175.4010807@nthpermutation.com>
To: Michael StJohns <msj@nthpermutation.com>
Date: Mon, 30 Sep 2013 20:00:07 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130930180007.65F4B1A9C2@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Private Key Security [Was Re: DHE key derivation]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Sep 2013 18:00:18 -0000
Michael StJohns wrote: > > With respect to whether a key will be stolen or not, you really need > only compare the value of the data being protected by that key to the > cost to an attacker to retrieve that key (and the data). If the value > of the data is >> or >>> than the cost to attack, chances are someone > has done so. If someone if after the data, then it will go after the data, not after the keys. > > HSMs increase the cost of attack and that's a good reason to use them, For the vast majority of useful attacks it is entirely irrelevant whether your keys are in a HSM or not. First of all, HSMs will always and significantly increase the cost of setting up and running a TLS peer by a significant amount, and in particular, for a server, when performance is an issue. HSMs also do not scale with multi-core CPUs; instead, you got to pay factors more for a faster HSM. With existing TLS, your HSM would have to implement current TLS versions in its entirety, which most of the current HSMs probably do not. And interop with current TLS is likely going to be necessary for another two decades (SSLv3 is 18 years old and we only recently managed to put SSLv2 to rest (on paper, that is)). Even when you have your keys in a HSM, this will not prevent that a subverted server could look at incoming connections and perform TLS-protected communication with a purely software-based TLS protocol and software-based keys with the attacker. In many situations, the value is primarily in the data of the server, i.e. access to data the server is processing or has on persistent storage. Listening into communication and determining which client does what might be interesting for collection by spooks (NSA, GCQH, etc.) for performing data mining on the bigger picture, but is pretty irrelevant for the average malfeasant attacker. Being able to impersonate users might be *MUCH* more interesting to attackers than being able to listen into boring communication, e.g. obtaining credentials for users by various means, such as pulling them from the data persistence, modifying access control lists, capturing credentials of a disclosing authentication within the server (rather than trying to sniff and decrypt them from the network), setting/overwriting user credentials, creating new admin users, adding X.509 trust anchors for acceptable TLS client certs and probably lots of other things that are more powerful and more devastating than obtaining the server's boring private key. -Martin
- [TLS] New Algorithm identifier for EDH > 1024 bit… Phillip Hallam-Baker
- Re: [TLS] New Algorithm identifier for EDH > 1024… Wan-Teh Chang
- Re: [TLS] New Algorithm identifier for EDH > 1024… Yngve N. Pettersen
- Re: [TLS] New Algorithm identifier for EDH > 1024… Yaron Sheffer
- Re: [TLS] New Algorithm identifier for EDH > 1024… Peter Gutmann
- Re: [TLS] New Algorithm identifier for EDH > 1024… Yoav Nir
- [TLS] DHE key derivation Yaron Sheffer
- Re: [TLS] DHE key derivation Michael D'Errico
- Re: [TLS] DHE key derivation Martin Rex
- Re: [TLS] DHE key derivation Daniel Kahn Gillmor
- Re: [TLS] DHE key derivation Michael D'Errico
- Re: [TLS] DHE key derivation Michael D'Errico
- Re: [TLS] DHE key derivation Michael D'Errico
- Re: [TLS] DHE key derivation Daniel Kahn Gillmor
- Re: [TLS] DHE key derivation Hanno Böck
- Re: [TLS] DHE key derivation Hanno Böck
- Re: [TLS] DHE key derivation Yaron Sheffer
- Re: [TLS] DHE key derivation Yoav Nir
- [TLS] Private Key Security [Was Re: DHE key deriv… Michael StJohns
- Re: [TLS] Private Key Security [Was Re: DHE key d… Martin Rex
- Re: [TLS] New Algorithm identifier for EDH > 1024… Martin Rex
- Re: [TLS] New Algorithm identifier for EDH > 1024… Daniel Kahn Gillmor