From patchwork Wed Jan 23 19:29:53 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Breno Matheus Lima X-Patchwork-Id: 1030128 X-Patchwork-Delegate: sbabic@denx.de Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.denx.de (client-ip=81.169.180.215; helo=lists.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=nxp.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=nxp.com header.i=@nxp.com header.b="ZankHBmQ"; dkim-atps=neutral Received: from lists.denx.de (dione.denx.de [81.169.180.215]) by ozlabs.org (Postfix) with ESMTP id 43lFlC5rYgz9s3l for ; Thu, 24 Jan 2019 06:31:19 +1100 (AEDT) Received: by lists.denx.de (Postfix, from userid 105) id 58AF0C21DFF; Wed, 23 Jan 2019 19:30:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_BLOCKED, SPF_HELO_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.denx.de (localhost [IPv6:::1]) by lists.denx.de (Postfix) with ESMTP id 9828CC21E15; Wed, 23 Jan 2019 19:30:14 +0000 (UTC) Received: by lists.denx.de (Postfix, from userid 105) id C06C0C21DF9; Wed, 23 Jan 2019 19:29:58 +0000 (UTC) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10062.outbound.protection.outlook.com [40.107.1.62]) by lists.denx.de (Postfix) with ESMTPS id F3167C21DAF for ; Wed, 23 Jan 2019 19:29:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ewa5Dng0rDpqwXzThJjvUT0Pb12Eje/dA1kD+oT9Cr8=; b=ZankHBmQMjMAE9OVR2vQa73RzazXoWrZVyNuI8KjWYAS10dGpbcrtllAzzWtIMyEcRr4bLA+BKOrU6rh8b1nLotITlxcbGekg9KzRiYKMtvm7doP4aVM+lIRZZSRaF0c7GUHo/FILv1XWlWY6pEO+Wz2gQNLxNDgh9vlnr1aieU= Received: from DB7PR04MB4636.eurprd04.prod.outlook.com (52.135.138.158) by DB7PR04MB5307.eurprd04.prod.outlook.com (20.176.236.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17; Wed, 23 Jan 2019 19:29:53 +0000 Received: from DB7PR04MB4636.eurprd04.prod.outlook.com ([fe80::ad79:c2:afcd:9b85]) by DB7PR04MB4636.eurprd04.prod.outlook.com ([fe80::ad79:c2:afcd:9b85%3]) with mapi id 15.20.1537.031; Wed, 23 Jan 2019 19:29:53 +0000 From: Breno Matheus Lima To: "fabio.estevam@gmail.com" , "sbabic@denx.de" Thread-Topic: [PATCH 2/6] doc: imx: habv4: Add HABv4 introduction Thread-Index: AQHUs1IDiFrpptVYQk6ZWiyJFi3w6w== Date: Wed, 23 Jan 2019 19:29:53 +0000 Message-ID: <1548271740-177-3-git-send-email-breno.lima@nxp.com> References: <1548271740-177-1-git-send-email-breno.lima@nxp.com> In-Reply-To: <1548271740-177-1-git-send-email-breno.lima@nxp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.157.242.222] x-clientproxiedby: SN6PR04CA0037.namprd04.prod.outlook.com (2603:10b6:805:2a::14) To DB7PR04MB4636.eurprd04.prod.outlook.com (2603:10a6:5:36::30) authentication-results: spf=none (sender IP is ) smtp.mailfrom=breno.lima@nxp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: git-send-email 2.7.4 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR04MB5307; 6:6CMmlVHCLABeIL5AstWQJtqrEPiO09v1qyvMYU8LqvYLjtVlXSHd8e6QNtp8hTXGmzDCXuzbIh+H2eOQ6T19o1BeKRpAIpjmfDYRP66bdUcTR8Rsz3xJl2xSnEjDpPa/zwPpQYRy6OnZTqHw15tQ/rHdy5wfV7cQDuptl495IMC4fdLAgOeEkP2YovKtBnBlphfzb2JSEejo5QbHrzkyQkLIXtSZrWo5zPRE5/FJiKEn3YN5F43RBWqaXMbTQfCvcGkeJ8bdfRhMoEABp7Gau4Wjm3UfPsTxo4sC/L7H4fvijSYl7z0SP6wOZQ67yMPpJOLgGFIJh3YNhexbKtKZxHKMlBEz0uYe6DUw2DzbmdEP4sGfoxANYHKcVaGI3c9APlacoHlPbpF/zeY06lzMX2DDSITY3l61YkLHP3S3jQcK7fzGUZ0yxYdAZuKSC5RxAArmelsuXrZ8KyT5nCGtDA==; 5:yN9lYU5rHMKN/GGmsZ5dh2bSzS6+tC5GqTLtFAh4AojShHS5UoMh0oO4Ivgu2A5fKvLKtDyFJYgW8klWyF21g2UrnSH2MDjXpme4zomSS35/fMp/glp6WtQ6mpFlo3rDyCjcVR4sm3kXiQlvIqezudW7CmwjXP/2xy+M0gd7fc6kbAvCEnW6z5VTFNgyZtPm6CnVWJsxNP36nKAlNlJf1g==; 7:d4AZpC7GMWltZmbAVCiL3GILrAusMzVS7qnfUytNouIBcu6p6qcDjIR5Qlv7YmAPjmx/S5KHhpk7qDInN0zy/97AYkUnp/EQ19XmQujhlOCC7ORwRDhgHDLjObG620mmpE6rhxKL+5XgIKJLX/iM6g== x-ms-office365-filtering-correlation-id: 86b93660-b947-46f5-0742-08d681692610 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DB7PR04MB5307; x-ms-traffictypediagnostic: DB7PR04MB5307: x-microsoft-antispam-prvs: x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(396003)(376002)(136003)(189003)(199004)(6486002)(81166006)(6436002)(39060400002)(71190400001)(8936002)(71200400001)(2906002)(4326008)(446003)(30864003)(81156014)(8676002)(53936002)(478600001)(476003)(2616005)(11346002)(14444005)(256004)(66066001)(486006)(6512007)(36756003)(186003)(7736002)(66574012)(76176011)(316002)(97736004)(54906003)(110136005)(102836004)(105586002)(86362001)(2501003)(305945005)(3846002)(6116002)(52116002)(26005)(68736007)(99286004)(50226002)(6506007)(14454004)(386003)(25786009)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR04MB5307; H:DB7PR04MB4636.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CJLMZ/PUgWZARUunX8f9Gf9EylLn9SHgwrteltdAwIhLWkuEVzi/MezQYn7AiVeyHnIhTxJ5WWbobneq29a7Lo+UD5KvsmBNHV/Hk8gjZKlYAJIlXaI7W6bqbmbcbmwqeEGBHlDdjw/L93qhHmmK+ueu0hUlnX9tj/dmz7npqFYV8B4zGquUn7Gs4xQBnRT0oyXUwGEcNDAy1Mle90QUeKHGfjALOhytZ/URMZdAo/zF0rR/P/Quoo9wITwpQNeV1QTTuBjfCzd/4M6hDJIX6xlkyqS9cSilLG1hlkx1dvbfXDK2R3s4JemNd0DnSQran2io0wFZgMDHu7ZigezAMOwEvGGNGAJaujYBokRDzQrw3F25Kgu1zs6IRz+VLAevaphxSME8mwhc1Gg0+nzdHezHjjW0P9NYk/hTRaSlhzc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86b93660-b947-46f5-0742-08d681692610 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2019 19:29:47.6970 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR04MB5307 Cc: Breno Matheus Lima , "u-boot@lists.denx.de" Subject: [U-Boot] [PATCH 2/6] doc: imx: habv4: Add HABv4 introduction X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.18 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" The HABv4 is supported in i.MX50, i.MX53, i.MX6, i.MX7, series and i.MX 8M, i.MX8MM devices. Add an introductory document containing the following topics: - HABv4 Introduction - HABv4 Secure Boot - HABv4 Encrypted Boot - HAB PKI tree generation - HAB Fast Authentication PKI tree generation - SRK Table and SRK Hash generation Reviewed-by: Ye Li Reviewed-by: Utkarsh Gupta Signed-off-by: Breno Lima --- doc/imx/habv4/introduction_habv4.txt | 262 +++++++++++++++++++++++++++ 1 file changed, 262 insertions(+) create mode 100644 doc/imx/habv4/introduction_habv4.txt diff --git a/doc/imx/habv4/introduction_habv4.txt b/doc/imx/habv4/introduction_habv4.txt new file mode 100644 index 0000000000..25711bbe95 --- /dev/null +++ b/doc/imx/habv4/introduction_habv4.txt @@ -0,0 +1,262 @@ + +=======================================================+ + + i.MX Secure and Encrypted Boot using HABv4 + + +=======================================================+ + +1. Introduction +---------------- + +The i.MX family of applications processors provides the High Assurance Boot +(HAB) feature in the on-chip ROM. The ROM is responsible for loading the +initial program image (U-Boot) from the boot media and HAB enables the ROM +to authenticate and/or decrypt the program image by using cryptography +operations. + +This feature is supported in i.MX 50, i.MX 53, i.MX 6, i.MX 7 series and + i.MX 8M, i.MX 8MM devices. + +Step-by-step guides are available under doc/imx/habv4/guides/ directory, +users familiar with HAB and CST PKI tree generation should refer to these +documents instead. + +1.1 The HABv4 Secure Boot Architecture +--------------------------------------- + +The HABv4 secure boot feature uses digital signatures to prevent unauthorized +software execution during the device boot sequence. In case a malware takes +control of the boot sequence, sensitive data, services and network can be +impacted. + +The HAB authentication is based on public key cryptography using the RSA +algorithm in which image data is signed offline using a series of private +keys. The resulting signed image data is then verified on the i.MX processor +using the corresponding public keys. The public keys are included in the CSF +binary and the SRK Hash is programmed in the SoC fuses for establishing the +root of trust. + +The diagram below illustrate the secure boot process overview: + + Host PC + CST i.MX + HAB + +----------+ +----------+ + ---> | U-Boot | | Compare | + | +----------+ +----------+ + | | ^ ^ + | v Reference / \ Generated + | +----------+ Hash / \ Hash + | | Hash | Private / \ + | +----------+ Key / \ + | | | +----------+ +----------+ + | v | | Verify | | Hash | + | +----------+ | +----------+ +----------+ + | | Sign | <--- SRK ^ ^ + | +----------+ HASH \ / + | | | CSF \ / U-Boot + | v v \ / + | +----------+ +----------+ +----------+ + | | U-Boot | | | | U-Boot | + ---> | + | -----> | i.MX | -----> | + | + | CSF | | | | CSF | + +----------+ +----------+ +----------+ + +The U-Boot image to be programmed into the boot media needs to be properly +constructed i.e. it must contain a proper Command Sequence File (CSF). + +The CSF is a binary data structure interpreted by the HAB to guide +authentication process, this is generated by the Code Signing Tool[1]. +The CSF structure contains the commands, SRK table, signatures and +certificates. + +Details about the Secure Boot and Code Signing Tool (CST) can be found in +the application note AN4581[2] and in the secure boot guides. + +1.2 The HABv4 Encrypted Boot Architecture +------------------------------------------ + +The HAB Encrypted Boot feature available in CAAM supported devices adds an +extra security operation to the bootloading sequence. It uses cryptographic +techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used +by unauthorized users. This mechanism protects the U-Boot code residing on +flash or external memory and also ensures that the final image is unique +per device. + +The process can be divided into two protection mechanisms. The first mechanism +is the bootloader code encryption which provides data confidentiality and the +second mechanism is the digital signature, which authenticates the encrypted +image. + +Keep in mind that the encrypted boot makes use of both mechanisms whatever the +order is (sign and then encrypt, or encrypt and then sign), both operations +can be applied on the same region with exception of the U-Boot Header (IVT, +boot data and DCD) which can only be signed, not encrypted. + +The diagram below illustrate the encrypted boot process overview: + + Host PC + CST i.MX + HAB + +------------+ +--------------+ + | U-Boot | | U-Boot | + +------------+ +--------------+ + | ^ + | | + v DEK +--------------+ + +------------+ | ----> | Decrypt | + | Encrypt | <--- | +--------------+ + +------------+ DEK | ^ + | | | + | Private | | + v Key +------+ +--------------+ + +------------+ | | CAAM | | Authenticate | + | Sign | <--- +------+ +--------------+ + +------------+ DEK ^ ^ + | + OTPMK DEK \ / U-Boot + | | Blob \ / + CSF + v v \ / + +------------+ +----------+ +------------+ + | Enc U-Boot | | | | Enc U-Boot | + | + CSF | ----> | i.MX | -------> | + CSF | + | + DEK Blob | | | | + DEK Blob | + +------------+ +----------+ +------------+ + ^ | + | | + --------------------- + DEK Blob + (CAAM) + +The Code Signing Tool automatically generates a random AES Data Encryption Key +(DEK) when encrypting an image. This key is used in both encrypt and decrypt +operations and should be present in the final image structure encapsulated +by a CAAM blob. + +The OTP Master Key (OTPMK) is used to encrypt and wrap the DEK in a blob +structure. The OTPMK is unique per device and can be accessed by CAAM only. +To further add to the security of the DEK, the blob is decapsulated and +decrypted inside a secure memory partition that can only be accessed by CAAM. + +During the design of encrypted boot using DEK blob, it is necessary to inhibit +any modification or replacement of DEK blob with a counterfeit one allowing +execution of malicious code. The PRIBLOB setting in CAAM allows secure boot +software to have its own private blobs that cannot be decapsulated or +encapsulated by any other user code, including any software running in trusted +mode. + +Details about DEK Blob generation and PRIBLOB setting can be found in the +encrypted boot guide and application note AN12056[3] . + +2. Generating a PKI tree +------------------------- + +The first step is to generate the private keys and public keys certificates. +The HAB architecture is based in a Public Key Infrastructure (PKI) tree. + +The Code Signing Tools package contains an OpenSSL based key generation script +under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI +tree containing up to 4 Super Root Keys (SRK) as well as their subordinated +IMG and CSF keys. + +A new PKI tree can be generated by following the example below: + +- Generating 2048-bit PKI tree on CST v3.1.0: + + $ ./hab4_pki_tree.sh + ... + Do you want to use an existing CA key (y/n)?: n + Do you want to use Elliptic Curve Cryptography (y/n)?: n + Enter key length in bits for PKI tree: 2048 + Enter PKI tree duration (years): 5 + How many Super Root Keys should be generated? 4 + Do you want the SRK certificates to have the CA flag set? (y/n)?: y + +The diagram below illustrate the PKI tree: + + +---------+ + | CA | + +---------+ + | + | + --------------------------------------------------- + | | | | + | | | | + v v v v + +--------+ +--------+ +--------+ +--------+ + | SRK1 | | SRK2 | | SRK3 | | SRK4 | + +--------+ +--------+ +--------+ +--------+ + / \ / \ / \ / \ + v v v v v v v v + +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ + |CSF1| |IMG1| |CSF2| |IMG2| |CSF3| |IMG3| |CSF4| |IMG4| + +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ + +After running the script users can check the private keys under keys/ directory +and their respective X.509v3 public key certificates under crts/ directory. +Those files will be used during the signing and authentication process. + +2.1 Generating a fast authentication PKI tree +---------------------------------------------- + +Starting in HAB v4.1.2 users can use a single SRK key to authenticate the both +CSF and IMG contents. This reduces the number of key pair authentications that +must occur during the ROM/HAB boot stage, thus providing a faster boot process. + +The script hab4_pki_tree.sh is also able to generate a Public Key Infrastructure +(PKI) tree which only contains SRK Keys, users should not set the CA flag when +generating the SRK certificates. + +- Generating 2048-bit fast authentication PKI tree on CST v3.1.0: + + $ ./hab4_pki_tree.sh + ... + Do you want to use an existing CA key (y/n)?: n + Do you want to use Elliptic Curve Cryptography (y/n)?: n + Enter key length in bits for PKI tree: 2048 + Enter PKI tree duration (years): 5 + How many Super Root Keys should be generated? 4 + Do you want the SRK certificates to have the CA flag set? (y/n)?: n + +The diagram below illustrate the PKI tree generated: + + +---------+ + | CA | + +---------+ + | + | + --------------------------------------------------- + | | | | + | | | | + v v v v + +--------+ +--------+ +--------+ +--------+ + | SRK1 | | SRK2 | | SRK3 | | SRK4 | + +--------+ +--------+ +--------+ +--------+ + +2.2 Generating a SRK Table and SRK Hash +---------------------------------------- + +The next step is to generated the SRK Table and its respective SRK Table Hash +from the SRK public key certificates created in one of the steps above. + +In the HAB architecture, the SRK Table is included in the CSF binary and the +SRK Hash is programmed in the SoC SRK_HASH[255:0] fuses. + +On the target device during the authentication process the HAB code verify the +SRK Table against the SoC SRK_HASH fuses, in case the verification success the +root of trust is established and the HAB code can progress with the image +authentication. + +The srktool can be used for generating the SRK Table and its respective SRK +Table Hash. + +- Generating SRK Table and SRK Hash in Linux 64-bit machines: + + $ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e \ + SRK_1_2_3_4_fuse.bin -d sha256 -c \ + SRK1_sha256_2048_65537_v3_ca_crt.pem,\ + SRK2_sha256_2048_65537_v3_ca_crt.pem,\ + SRK3_sha256_2048_65537_v3_ca_crt.pem,\ + SRK4_sha256_2048_65537_v3_ca_crt.pem + +The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further +steps as explained in HAB guides available under doc/imx/habv4/guides/ +directory. + +References: +[1] CST: i.MX High Assurance Boot Reference Code Signing Tool. +[2] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using + HABv4" - Rev 2. +[3] AN12056: "Encrypted Boot on HABv4 and CAAM Enabled Devices" - Rev. 1