Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1385387yba; Thu, 16 May 2019 20:52:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqy/hpoGW11lyC9umCNbs0zDwgMfx1K56fUmlknC/d2hatz4GbR5Z9pCFq6oqIq5D1T9bofk X-Received: by 2002:a62:604:: with SMTP id 4mr58376711pfg.38.1558065156628; Thu, 16 May 2019 20:52:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558065156; cv=none; d=google.com; s=arc-20160816; b=zI68uxu3BveFRGzpVOmskAwirZzsQSZ3Wjz+Y/7Ql6Q8Znf3SCC2NcmpX0fa2CxRMA FdswrAGWZ60deB9zXV6hU5LP/aPdfQnAIt4J5WX8eZx99p8eIXy0AwagqdmY1FsYlugm 7Z/BzJOvhcHfp93ic0/qO4eBgVptR5A6jLQkxnCD1fWO3+Wec+6BB1rZFSn1kn0vjqBv IIA8zPLuv5UDhBRqx5AfQUuT0PR4z4cn3xBdqT3eW7zFDvmXSelik9xmCkNC7OmsSHUg 4hVysT061WAS2ib0yatUoyrSKh7Mf2Szm40F1jJwMqYbWB8iNTgEqYML+NwHKomc2Vro Z2Ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=A0Mbnz8+mbEE4YHtN+WCYGct6UwrCMRIp8VoCubc4so=; b=rcLLv05Au5vSc6DjlqAo5WpPgiaZyRJdrwhHsSGY3YVB/zN7W79o68hL1thp2Rr4nX kaNYf+3yeyC7UCX3iG8AMvvdM1OHvbIi6tZGRHBv6NxQFnD1/7VisCbG0c29GAQ7/NFs Wzs6zi0co6hOPYjBrbkiL+RGfnpqOE9l0vONprijX6DOI3+z07piHAAzJuyh350EsZG9 0lhc4/1zY5dl3yt8/EqTzJieqIyqFAfAJjTZXHAzBE7Er28nlz8LOmMj6CFpCu46uz6s jqjF5xeJ5cHyOkUkO7q3aB2qmSLYT9BnBqTczvdwbzga8AF68naMEsJTuWL2lWh57DwU 46Ow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k83si7655863pfb.101.2019.05.16.20.52.08; Thu, 16 May 2019 20:52:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727467AbfEQB3c (ORCPT + 99 others); Thu, 16 May 2019 21:29:32 -0400 Received: from linux.microsoft.com ([13.77.154.182]:60864 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726839AbfEQB3c (ORCPT ); Thu, 16 May 2019 21:29:32 -0400 Received: from [10.200.157.26] (unknown [131.107.147.154]) by linux.microsoft.com (Postfix) with ESMTPSA id 51CAE20110AD; Thu, 16 May 2019 18:29:31 -0700 (PDT) Subject: Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log To: Ken Goldman , Linux Integrity , Mimi Zohar , David Howells , James Morris , Linux Kernel Cc: Balaji Balasubramanyan , Prakhar Srivastava References: <6b69f115-96cf-890a-c92b-0b2b05798357@linux.microsoft.com> <750fdb9f-fc9b-24bf-42c3-32156ecdc16f@linux.ibm.com> From: Lakshmi Message-ID: <9c944ba6-f520-96e1-3631-1e21bbc4c327@linux.microsoft.com> Date: Thu, 16 May 2019 18:29:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <750fdb9f-fc9b-24bf-42c3-32156ecdc16f@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/16/19 7:34 AM, Ken Goldman wrote: >> But outside the client machine this key id is not sufficient to >> uniquely determine which key the signature corresponds to. > > Why is this not sufficient? > > In my implementation, I create a lookup table at the attestation service > that maps the 4-byte IMA log key identifier to the signing public key. > > Are you concerned about collisions?  Something else? Yes - the concern is collision. The "Subject Key Identifier" (SKI) for no two certificate can be the same. But since we are using only the last 4 bytes of the SKI it can collide. That's mainly the reason I want to log the entire public key. > > Are you suggesting that the client supply the verification public key > and that the verifier trust it?  Wouldn't that make the log self signed? > > How would the verifier determine that the key from the IMA log is valid > / trusted / not revoked from the log itself? IMA log is backed by the TPM. So if the public key is added to the IMA log the attestation service can validate the key information. I am not sure if that answers your question. > > A minor question here. > > Are you proposing that the IMA log contain a single ima-sigkey entry per > public key followed by ima-sig entries? > > Or are you proposing that ima-sig be replaced by ima-sigkey, and that > each event would contain both the signature and the public key? > > If the latter, this could add 25M to a server's 100K log.  Would that > increase in size concern anyone?  Could it be a concern on the other > end, an IoT device with limited memory? Mimi had raised the same concern. I will update my implementation to include the certification information in the IMA log only once per key - when that key is added to the IMA or Platform keyring. Thanks, -lakshmi