Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp677914pxf; Thu, 11 Mar 2021 12:06:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJxtJRr96SwoajW8HtfFL9CbPNwhupjVk5fVwzFvhP42qJa3M6HlRoe3dhn2QGLQk7O3qQY9 X-Received: by 2002:a17:906:5d05:: with SMTP id g5mr4643082ejt.489.1615493218631; Thu, 11 Mar 2021 12:06:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615493218; cv=none; d=google.com; s=arc-20160816; b=ZYCXHulJ0HXxfZPay6Fhv/sMtrX02vYxEaqil4xpOBIHTJ2ptPXs+t7lFk18P0JDqb U6uYD+EWHaAVXfPXbEwzsB5HMGdCrcPRhhMY6iihv6hpvxsPuYHwGwgAQ4q5kehdSvb6 DfVlTR0yGz6xmTdjGGqIV3QnJk7sbanaFtrW82UuX1a5GtfUMLg+BA8FC4EZzEhTN9U6 Owt6b44EglupafhsQnr7DKTBUHTaN4isayedP3ir53dIkbRdZrhjadOoOf6nNoNjng+d WX6YGUNrol9YL1DIuSB5TQskwQrKVj3YwkIRVQZPf03zTlHv5JzicN7Hmw12l2vOtv3E fYvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=3x71OsvLMf0nFUdp7F4i/x7yEc+H6Z4uDjUyXw3D+Dw=; b=WxKjguuJ3SVdDDKPM4NsSnYV0OG7oF9ng3egCejIRdsbfz0M4iMCMlQCanAzUkeYJl zGpIES2lVwdcqlA9sYvQXmMSO/5SX37AvJdk5uQLpYy/5oJ5oJ1p6dbW/B7ls0vQF3hC 3mxoYPHXu0+BhLpEwmvR/gfT863+3dOaAEISI1iAdW1kLbYiF2VOlrIf98/Ix1w6Cat2 B4ShV/MfRjLzGagWgfnSI+PN/0DUIQbU7qWqrrhdscSErZJO1LX7NBWAI95YNeJTVfyA 4+mIsPFrQxQMnZamD0SBitDUnBPcoLcg3BLVcTCjxo0+E7czY6+/dmldESfNWQXEAcyl lU4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de1si2370485edb.413.2021.03.11.12.06.35; Thu, 11 Mar 2021 12:06:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230283AbhCKUCt (ORCPT + 99 others); Thu, 11 Mar 2021 15:02:49 -0500 Received: from [212.63.208.185] ([212.63.208.185]:43780 "EHLO mail.marcansoft.com" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S229796AbhCKUCh (ORCPT ); Thu, 11 Mar 2021 15:02:37 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 7A616424D9; Thu, 11 Mar 2021 20:02:24 +0000 (UTC) To: Linus Walleij Cc: David Howells , "open list:ASYMMETRIC KEYS" , Jarkko Sakkinen , Sumit Garg , Arnd Bergmann , Joakim Bech , =?UTF-8?Q?Alex_Benn=c3=a9e?= , "linux-kernel@vger.kernel.org" , Maxim Uvarov , Ilias Apalodimas , Ruchika Gupta , "Winkler, Tomas" , yang.huang@intel.com, bing.zhu@intel.com, Matti.Moell@opensynergy.com, hmo@opensynergy.com, linux-mmc , linux-scsi , linux-nvme@vger.kernel.org, Ulf Hansson , Arnd Bergmann References: <20210303135500.24673-1-alex.bennee@linaro.org> <20210303135500.24673-2-alex.bennee@linaro.org> <20210305075131.GA15940@goby> <6c542548-cc16-af68-c755-df52bd13b209@marcan.st> <0a26713a-8988-1713-4358-bc62364b9e25@marcan.st> <32bdceb1-e70d-7481-96e3-a064a7108eb9@marcan.st> From: Hector Martin Subject: Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem Message-ID: Date: Fri, 12 Mar 2021 05:02:22 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/03/2021 23.06, Linus Walleij wrote: > Yes. And this is what mobile phone vendors typically did. > > But the nature of different electrical attacks made them worried > about different schemes involving cutting power and disturbing > signals with different probes, so they wanted this counter > implemented in hardware and that is why RPMB exists at all > (IIUC). No, prior to RPMB there was no such secure counter at all. The problem is that non-volatile erasable storage (i.e. EEPROM/Flash) is incompatible with modern SoC manufacturing processes, so there is no way to embed a secure counter into the main SoC. And once your counter needs to be external, there needs to be a secure communications protocol to access it. This is what RPMB implements. For preventing software downgrades, especially of bootloader code, this can be implemented with one-time fuses embedded in the SoC, but there is a limited supply of those. So this doesn't work for things like PIN attempt counters. For that you need a secure external counter. > It is fine to be of the opinion that this entire piece of hardware > is pointless because the same can be achieved using > well written software. You've misunderstood me. RPMB isn't pointless; what I am saying is that if you strip away everything but the counter functionality, you can still build equivalent security guarantees. You still need the counter. There is no way to get that counter without RPMB or something like it (another option is e.g. to use a smartcard IC as a secure element; AIUI modern Apple devices do this). Software alone doesn't work. This is why I wrote that article about how the FBI cracks iPhones; that works because they weren't using a secure rollback-protected storage/counter chip of any kind. > The position that the kernel community shall just ignore this > hardware is a possible outcome of this discussion, but we need > to have the discussion anyway, because now a RPMB framework > is being promoted. The people who want it will need to sell it to > us. Again, you're kind of misunderstanding me here. I'm not saying the feature is useless. What I'm saying is that, to understand *how* it is useful, it helps if you forget about the read/write commands and treat it as a simple counter. Once you do that, you'll realize that e.g. putting keys in RPMB doesn't really make sense as a kernel primitive. The usefulness of RPMB is purely in the integration of that counter (which is equivalent to rollback-protected storage) with a policy system. Everything else is icing on the cake; it doesn't create new use cases. Consider this: * You have RPMB, but you will use it as a counter only. * To use RPMB, you need to have a secure shared key. * You use the RPMB key (or a hash, or whatever) to encrypt a GPG key in your filesystem * You have a Git repo. This is your secure rollback-protected storage. * We assume the filesystem can be potentially read, written, and intercepted. To read from your rollback-protected storage, you: * Read the RPMB counter securely * Fetch the Git tag named "v%d" with the counter value * Ensure the Git tag is correctly signed with your secure GPG key * Ensure the commit description of the signed commit is also "v%d" To write to your rollback protected storage, you: * Commit your changes to the repository (as a child of the current known good commit, which you know is secure via the prevous read process) with the commit message "v%d" with the counter value + 1 * Tag it "v%d" with the current counter value + 1, signing the tag with your GPG private key * Ensure all changes are flushed to disk * Perform an increment operation on the RPMB counter You have now built a secure, rollback-protected Git repository, with similar security properties to RPMB storage, without using RPMB storage; just a counter. Just like RPMB storage, the repo is readable without a key. Just like RPMB storage, you need to have a secured master key stored somewhere; if the attacker gets your key it is game over. Just like RPMB storage, the repo can only be updated (in a way that would be accepted) with the key available Just like RPMB storage, the repo cannot be rolled back to a prior version (because it would not match the counter value) Thus, we can conclude that the storage features of RPMB do not provide additional security properties that cannot be derived from a simple counter. * Disclaimer: please don't actually deploy this; I'm trying to make a point here, it's 5AM and I'm not claiming this is a perfectly secure design and I haven't missed anything. Please don't design rollback-protected Git repositories without expert review. I am assuming filesystem mutations only happen between operations and handwaving away active attacks, which I doubt Git is designed to be robust against. A scheme like this can be implemented securely with care, but not naively. >>> With RPMB this can be properly protected against because >>> the next attempt can not be made until after the RPMB >>> monotonic counter has been increased. >> >> But this is only enforced by software. If you do not have secure boot, >> you can just patch software to allow infinite tries without touching the >> RPMB. The RPMB doesn't check PINs for you, it doesn't even gate read >> access to data in any way. All it does is promise you cannot make the >> counter count down, or make the data stored within go back in time. > > This is true, I guess the argument is something along the > line that if one link in the chain is weaker, why harden > any other link, the chain will break anyway? This is how security works, yes :-) I'm not saying hardening a link in the chain is pointless in every case, but in this case it's like heat treating one link in the chain, then joining it to the next one with a ziptie. Only once you at least have the entire chain of steel does it make sense to start thinking about heat treatment. > I am more of the position let's harden this link if we can > and then deal with the others when they come up, i.e. > my concern is this piece of the puzzle, even if it is not > the centerpiece (maybe the centerpiece is secure boot > what do I know). Well, that's what I'm saying, you do need secureboot for this to make sense :-) RPMB isn't useless and some systems should implement it; but there's no real way for the kernel to transparently use it to improve security in general (for anyone) without the user being aware. Since any security benefit from RPMB must come from integration with user policy, it doesn't make sense to "well, just do something else with RPMB because it's better than nothing"; just doing "something" doesn't make systems more secure. There needs to be a specific, practical use case that we'd be trying to solve with RPMB here. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub