Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp573200imb; Fri, 1 Mar 2019 08:11:15 -0800 (PST) X-Google-Smtp-Source: APXvYqwBCIWpq2tw79pi0wqEF59gQ1MESSWm0yvpc02L1voQnxjPhfwL6+X//vqhQlG2u1QqCYIB X-Received: by 2002:a17:902:5a43:: with SMTP id f3mr6258410plm.161.1551456675669; Fri, 01 Mar 2019 08:11:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551456675; cv=none; d=google.com; s=arc-20160816; b=bYQvOl5o6SkscSMCAUO8svRYg5/xuFh768QoNld4/ihKucLJOF+7bdwZL++gjDcMah eXT4UJ4PMlAdo5vCTNDQEtZ2UklLoi5lT2RLvuN4lsNME/2nrWo4+FwWosHGJYj9F8I/ WVq1DxQEM5uYm1GCWOSQIn93Z53s6beczeRxR2L+ofvxy8Pl1A+erdWazTyvpuDz2S6E GdNQCv6p6tcG0AVPSU+udQhP/HhhonUal6IF5lhDhZ0+WUm2xx+Cwput074tHMQPtnbG BMYC0IzIXS18px63hX3E44zEwrVB0FiR6joXecJKq4Bl5VWODJG8iMwRYbjusst0OTDH vOXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=wSWc+NtMSeNmAG9qag9QVjGXNnqesUV6auJGlli80iU=; b=vELWNugbJMR4AqsKkTxyZhFKvV9XfI4aYw3TA/QnKADTcuNvk+2Z+agaflf7Max67n i+Oi6aXv3dA3qKFsSxlM2yLPJGtXJZLlNDOQqZ7ojMkWieoKet+T1pTpGZeMEdwyx+H4 d8eS54sFin+BeAeQCOsoruCiTUtrHrQVVuywxjwXvolCUWsn1A4LO04ECG4xHtKVOHcC Ey2EdXJhJpRuyOLO73Cz1uZo7YlbY46R+Ggw9Yt0ISpQXGzR4dtO4fJfFTtY8uf/2Hfo 5E1kSkNgWiCcY65J2Au9P/K5u4CBWiHDybNb/jdNLtNeXgXxeAVqIZ4wyUVia7cPguRh /Jnw== 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=nxp.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u22si20926403plq.145.2019.03.01.08.11.00; Fri, 01 Mar 2019 08:11:15 -0800 (PST) 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=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389008AbfCAQK3 (ORCPT + 99 others); Fri, 1 Mar 2019 11:10:29 -0500 Received: from inva021.nxp.com ([92.121.34.21]:55388 "EHLO inva021.nxp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387940AbfCAQK3 (ORCPT ); Fri, 1 Mar 2019 11:10:29 -0500 Received: from inva021.nxp.com (localhost [127.0.0.1]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 665A120008B; Fri, 1 Mar 2019 17:10:26 +0100 (CET) Received: from inva024.eu-rdc02.nxp.com (inva024.eu-rdc02.nxp.com [134.27.226.22]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 59877200024; Fri, 1 Mar 2019 17:10:26 +0100 (CET) Received: from sopsvulinux.ea.freescale.net (sopsvulinux.ea.freescale.net [10.161.69.178]) by inva024.eu-rdc02.nxp.com (Postfix) with ESMTP id 35F3E20642; Fri, 1 Mar 2019 17:10:26 +0100 (CET) Received: from SOPDPUATS05.ea.freescale.net (SOPDPUATS05.ea.freescale.net [10.161.66.238]) by sopsvulinux.ea.freescale.net (Postfix) with ESMTP id 4F6BA82C7B; Fri, 1 Mar 2019 17:08:45 +0100 (CET) From: Franck LENORMAND To: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org Cc: franck.lenormand@nxp.com, horia.geanta@nxp.com, silvano.dininno@nxp.com, agk@redhat.com, snitzer@redhat.com, dm-devel@redhat.com, dhowells@redhat.com, jmorris@namei.org, serge@hallyn.com Subject: [RFC PATCH 0/2] Create CAAM HW key in linux keyring and use in dmcrypt Date: Fri, 1 Mar 2019 17:09:57 +0100 Message-Id: <1551456599-10603-1-git-send-email-franck.lenormand@nxp.com> X-Mailer: git-send-email 2.7.4 X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This RFC aims to provide better security of users using CAAM block allowing them to encrypt their disks with a hardware key. A hardware key is a key only know by the hardware hence not known neither by the userspace nor the kernelspace. The use of hardware keys allows to mitigate attacks against systems using such type of keys as the key is more complicated to obtain. In effect, even a compromised kernel could not divulge the key used to encrypt the data. The user or the kernel can only configure a device mapper using the target crypt and provide the HW key to encrypt a disk. The CAAM possesses a mechanism to generate HW keys called "black key". The CAAM has the capacity to encrypt a plain key ("red key") with a key only accessible by the hardware hence creating a "black key". The encryption key used change at each reset of the CAAM: shutdown, reboot. generate a black key: -> CAAM -> To keep a black key between reset, it must be stored in filesystem in a structure called "black blob". This structure contains the "black key" but also encryption information. It is also generated by the CAAM using a key only accessible by the hardware but which doesn't change between reset of the CAAM. generate a black blob: -> CAAM -> -> FS obtain the black key: FS -> -> CAAM -> The creation of such structures and its use was not exposed to userspace so it was complicated to use and required custom development. We would like to ease this using interface which are known and used: - Linux key retention service : Allow to generate or load keys in a keyring which can be used by applications. - dm-crypt : device mapper allowing to encrypt data. The capacity to generate or load keys already available in the Linux key retention service does not allows to exploit CAAM capabilities hence we need to create a new key_type. The new key type "caam_tk" allows to: - Create a black key from random - Create a black key from a red key - Load a black blob to retrieve the black key The patch 01 presents the implementation of the key type is available in the RFC. This implementation is presented to give context but cannot be compiled as it requires other components not presented in this RFC. We target dm-crypt to perform the disk encryption. It can retrieve keys from the Linux key retention service however it only supports the key type "user" and "logon". In order to use keys from our new key type, we need to either: - add support for our new key type : dm-crypt need a reference on the key type structure. - support any key type : the reference on the key type is retrieved from the key subsystem based on the name of the key type The patch 02 present the implementation of the second solution. The main advantage of this implementation are: - The reference on the key type is no more needed at compile time - All future key type will be supported - Only the key type registered can be obtained (key type as module) We think that this modification of dm-crypt and the key subsystem will ease the use of dm-crypt and the development of key type. Franck LENORMAND (2): drivers: crypto: caam: key: Add caam_tk key type dm-crypt: Use any key type which is registered drivers/crypto/caam/caam_key.c | 623 +++++++++++++++++++++++++++++++++++++++++ drivers/crypto/caam/caam_key.h | 58 ++++ drivers/md/dm-crypt.c | 11 +- include/linux/key-type.h | 2 + security/keys/key.c | 42 +++ 5 files changed, 731 insertions(+), 5 deletions(-) create mode 100644 drivers/crypto/caam/caam_key.c create mode 100644 drivers/crypto/caam/caam_key.h -- 2.7.4