From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754385AbcBEQRV (ORCPT ); Fri, 5 Feb 2016 11:17:21 -0500 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:53774 "EHLO e23smtp02.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751081AbcBEQRT (ORCPT ); Fri, 5 Feb 2016 11:17:19 -0500 X-IBM-Helo: d23dlp02.au.ibm.com X-IBM-MailFrom: zohar@linux.vnet.ibm.com X-IBM-RcptTo: keyrings@vger.kernel.org;linux-kernel@vger.kernel.org;linux-security-module@vger.kernel.org Message-ID: <1454688979.2648.97.camel@linux.vnet.ibm.com> Subject: Re: [RFC PATCH 03/20] X.509: Allow X.509 certs to be blacklisted [ver #2] From: Mimi Zohar To: David Howells Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, petkan@mip-labs.com, linux-kernel@vger.kernel.org Date: Fri, 05 Feb 2016 11:16:19 -0500 In-Reply-To: <25815.1454514412@warthog.procyon.org.uk> References: <1453322001.9549.7.camel@linux.vnet.ibm.com> <20160119113026.23238.4498.stgit@warthog.procyon.org.uk> <20160119113049.23238.92240.stgit@warthog.procyon.org.uk> <25815.1454514412@warthog.procyon.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16020516-0005-0000-0000-000003436340 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Wed, 2016-02-03 at 15:46 +0000, David Howells wrote: > Mimi Zohar wrote: > > > > Allow X.509 certs to be blacklisted based on their TBS hash. > > > > What is the TBS hash? This doesn't seem to be the key identifier. > > It's the TBSCertificate hash (I'll change to calling it that in the patch > description). "TBS" stands for "To Be Signed". This is what is hashed for > the signature to be generated upon - so it's something we have to expend > resources calculating anyway. > > The reason I'm using this is this is what UEFI puts into its blacklist. See: > > http://uefi.blogspot.co.uk/2013/09/uefi-24-review-part-13-hash-of.html > > To quote: > > Now, in the UEFI 2.4 specification, three new types of signatures for > the black list were added. Specifically, the various recommended forms > of the To-Be-Signed hash value (160, 256 and 512-bits) which are > created during the creation of a certificate could be added to the > black list instead of the certificate itself. > > > The cert associated with this key identifier is loaded onto the .ima > > keyring. > > We could also check that. There's no requirement that we only check the TBS - > but the TBS hash is something we must check. Ok, but before "IMA: Use the system blacklist keyring" patch, this needs to be addressed. > I wonder if I should mark the blacklist key as to what the value it holds > should be checked against. There's a number of different things we could put > in there: > > (1) TBSCertificate hash. > > (2) Subject Key Identifier content. > > (3) Authenticode Binary hash (for PE files). > > (4) PKCS#7 component digest. Ok > > eg: openssl x509 -in -inform DER -notext -out > > > > > > > > X509v3 extensions: > > X509v3 Subject Key Identifier: > > > > 71:12:39:B3:AB:E6:8D:BF:70:E7:26:DE:C8:4A:3F:5F:17:EF:00:6C > > Note that this isn't a mandatoryy field and if it's not present, we have no way > to calculate it as there's no one standard-defined method. The hex string appears when displaying the keys. For example, keyctl show %keyring:.ima shows: 734429129 --als--v 0 0 \_ asymmetric: : local: signing key: 711239b3abe68dbf70e726dec84a3f5f17ef006c Mimi