[TLS] Private Key Security [Was Re: DHE key derivation]

Michael StJohns <msj@nthpermutation.com> Sun, 29 September 2013 17:20 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A898421E8050 for <tls@ietfa.amsl.com>; Sun, 29 Sep 2013 10:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.575
X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jQ-+zA6SI+f5 for <tls@ietfa.amsl.com>; Sun, 29 Sep 2013 10:20:48 -0700 (PDT)
Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 636BD21F85EF for <tls@ietf.org>; Sun, 29 Sep 2013 10:20:48 -0700 (PDT)
Received: by mail-qe0-f53.google.com with SMTP id jy17so3160669qeb.12 for <tls@ietf.org>; Sun, 29 Sep 2013 10:20:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cByqCGClbJ4hlKyZwyi/27qWdlT1cOyFuRcJOzJ4FyE=; b=QjeL//Gglbr35gALiCqe7XfkJkUyRIw2X536rFldTA4m4tbSVwtV2sOKnOX8XKYCjn EK6QkAGCgnGJNFpZEf4SiDVI08KI7gHuQqTmsG1nrsCPkYmM5B/iIARqhiS7gNoqx3mT DFq1+jmR0ackt4UryWCyqgNWmrxygtaY+CtN+/dVfRBONVfaMRNcbzyCpx6Ob3/0qYVv H+skj6fnqMvHwdHJMoxFTDirgkwH62SW/opSSWkqJTdhGXqfAwZDGdDBwSdPQ4O8x8ed f6jiFFktGjQN3QvGStdwXVCJjAHA26oJ1Vh5nVtxZyr2aT/VQ0qKstqxuvcYTBolev06 z9ZQ==
X-Gm-Message-State: ALoCoQllzi87UA/umxDNyDswOf6TNlYspXgp3fv5GFOgb2BT/kz1DdfSE0CnDANT1T20USuNpVRI
X-Received: by with SMTP id nm4mr23432237qeb.68.1380475247693; Sun, 29 Sep 2013 10:20:47 -0700 (PDT)
Received: from [] (c-68-83-212-126.hsd1.md.comcast.net. []) by mx.google.com with ESMTPSA id n9sm41819795qag.8.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Sep 2013 10:20:47 -0700 (PDT)
Message-ID: <52486175.4010807@nthpermutation.com>
Date: Sun, 29 Sep 2013 13:20:53 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
References: <CAMm+Lwioy8Z+wo7czrOT+5-HOf-G=8X3MF-bEjX2L0uxsXhO8Q@mail.gmail.com> <CALTJjxHeJ8WVuaTfSa5G7xQ1F21VRpYuQ0nDsym8vGL_MOrEVQ@mail.gmail.com> <op.w30xbev03dfyax@killashandra.invalid.invalid> <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com> <52459F3E.2050101@gmail.com> <20130927185535.5b971c1d@hboeck.de> <5245F1DE.10903@gmail.com>
In-Reply-To: <5245F1DE.10903@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [TLS] Private Key Security [Was Re: DHE key derivation]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Sun, 29 Sep 2013 17:20:54 -0000

On 9/27/2013 5:00 PM, Yaron Sheffer wrote:
> Just a few weeks ago we as a community thought the server's private 
> key was generally secure. Now the entire community seems to assume the 
> private key is easy to steal.

If the server private key isn't inside an HSM (hardware security module) 
of some sort, normal attacks on the server will make it possible to 
steal the key.  Even if encrypted at rest, to be used the key must be 
decrypted and moved to memory at some point.  Anyone who thought 
datafile based server private keys were unconditionally or even 
marginally secure probably hadn't thought it through.

If the server private key IS inside an HSM, the current way session keys 
are derived from the session master key makes it possible for an 
attacker to steal those keys unless the entire TLS negotiation and 
packet processing takes place inside an HSM specifically designed for 
that version of TLS.
> Practically, most private keys will probably not be stolen. 

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.

HSMs increase the cost of attack and that's a good reason to use them, 
but you still need to consider the relationship of the expected cost to 
attack to the value of the data being protected and adjust your 
protections if the value of the data - to the attacker - exceeds the 
attackers cost of attack.