Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755833AbbEUXJ0 (ORCPT ); Thu, 21 May 2015 19:09:26 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:36093 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbbEUXJX (ORCPT ); Thu, 21 May 2015 19:09:23 -0400 MIME-Version: 1.0 In-Reply-To: <20150521230105.GL23057@wotan.suse.de> References: <20150520162059.GC10473@localhost> <20150521213829.GH23057@wotan.suse.de> <20150521230105.GL23057@wotan.suse.de> From: Andy Lutomirski Date: Thu, 21 May 2015 16:09:00 -0700 Message-ID: Subject: Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4] To: "Luis R. Rodriguez" Cc: David Howells , Andy Lutomirski , Rusty Russell , Michal Marek , Matthew Garrett , keyrings@linux-nfs.org, Dmitry Kasatkin , "linux-kernel@vger.kernel.org" , Seth Forshee , LSM List , David Woodhouse Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3944 Lines: 85 On Thu, May 21, 2015 at 4:01 PM, Luis R. Rodriguez wrote: > On Thu, May 21, 2015 at 03:47:49PM -0700, Andy Lutomirski wrote: >> On Thu, May 21, 2015 at 3:31 PM, Luis R. Rodriguez wrote: >> > >> > Well as good as you are in 10 years we'll have better ones. So when >> > module signature went into the kernel the real expectation should have >> > been: >> > >> > This code looks good now but is going to be complete shit and >> > breakable a few years from now. >> > >> > Hence my first implicit and now explicit claims on dog and pony shows. >> > Best thing we can do IMHO is to just allow us to replace stupid human >> > code with better human code later, and eventually hopefully better AI >> > code, and so on. Since you don't have time for a real replacement >> > maybe what we can do is at least document / target / agree for what >> > pipe dream we want and shoot for it with time. Hopefully folks will >> > find time to implement it. >> >> I disagree. I'm a firm believer in security proofs. While I'm not >> trained in formal crypto proofs, I can sketch out a proof of why a >> system that properly tags its signatures is secure against a >> reasonable threat model. I can also show why that proof wouldn't work >> for a scheme without tags, and I can demonstrate the actual weakness >> in a scheme without tags. >> >> In ten years, the only reason a scheme that I say looks good would be >> because (a) I screwed up, (b) an underlying assumption is wrong, or >> (c) the implementation is subtly wrong. In particular, it won't fail >> because I'm insufficiently clever. >> >> A real professional expert would be less likely to screw up. >> >> (For reference, I wrote an actual doctoral thesis involving crypto.) > > OK, I think what I mentioned still holds: > > these premises must hold true for a period of time, and provided > you have all information. You cannot have all the information, so > the "threat model" depends on the reviewer, and the information they > have access to. So, still its still a dog and pony show, at least > a temporal one or one with a set of clauses. > >> > In the meantime should that block current dog and pony show trading? I >> > don't think so. >> >> Yes, since I can demonstrate the actual weakness without tags, > > But you don't want to do the work to provide a better replacement? Hell no. At least not until someone convinces me that I want any of this on any system I build. Thus far I'm unconvinced. Meanwhile, the threat model seems to be that you don't want an attacker not in possession of a distro-trusted or UEFI-trusted private key to cause the kernel to load incorrect firmware into a device or incorrect regulatory data. Without tagging the purpose of the signed file, you simply don't have a cryptographic guarantee of that. The bad guy can load something else that was signed for an entirely different purpose into the wrong device, possibly crashing it, causing buffer overflows because the format is wrong, or doing any number of other bad things. > >> and >> crypto is notoriously hard to fix once done poorly and there's a great >> history of obviously-theoretically-weak systems being meaningfully >> attacked in the real world. See, for example, every single old >> SSL/TLS cipher. (And yes, the crypto community knew what was wrong in >> theory and how to fix it when the protocol was designed. People just >> didn't pay attention.) > > Its a fair argument, but still -- we have the vaporware problem. If you write crypto verification code for firmware and I review it, and your code doesn't cryptographically protect it adequately, I'll say that in my review. That's all. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/