From: joeyli Subject: Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot Date: Thu, 26 Sep 2013 20:56:10 +0800 Message-ID: <1380200170.32302.85.camel__32508.4684802734$1380200210$gmane$org@linux-s257.site> References: <1380161957.32302.42.camel@linux-s257.site> <1380192218.32302.69.camel@linux-s257.site> <20130926120621.GA7537@amd.pavel.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Alan Stern , David Howells , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org, linux-pm@vger.kernel.org, linux-crypto@vger.kernel.org, opensuse-kernel@opensuse.org, "Rafael J. Wysocki" , Matthew Garrett , Len Brown , Josh Boyer , Vojtech Pavlik , Matt Fleming , James Bottomley , Greg KH , JKosina@suse.com, Rusty Russell , Herbert Xu , "David S. Miller" , "H. Peter Anvin" , Michal Marek , Gary Lin , Vivek Goyal To: Pavel Machek Return-path: Received: from smtp.nue.novell.com ([195.135.221.5]:41240 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756554Ab3IZM4W (ORCPT ); Thu, 26 Sep 2013 08:56:22 -0400 In-Reply-To: <20130926120621.GA7537@amd.pavel.ucw.cz> Sender: linux-crypto-owner@vger.kernel.org List-ID: =E6=96=BC =E5=9B=9B=EF=BC=8C2013-09-26 =E6=96=BC 14:06 +0200=EF=BC=8CPa= vel Machek =E6=8F=90=E5=88=B0=EF=BC=9A > Hi! >=20 > > For the symmetric key solution, I will try HMAC (Hash Message > > Authentication Code). It's already used in networking, hope the > > performance is not too bad to a big image. >=20 > Kernel already supports crc32 of the hibernation image, you may want > to take a look how that is done. In current kernel design, The crc32 is only for the LZO in-kernel hibernate, doesn't apply to non-compress hibernate and userspace hibernate. Put signature to snapshot header can support any kind of caller that's trigger hibernate. Any userspace hibernate tool will take the snapshot image from kernel, so, we need put the signature(or hash result) to snapshot header before userspace write it to anywhere.=20 >=20 > Maybe you want to replace crc32 with cryptographics hash (sha1?) and > then use only hash for more crypto? That way speed of whatever crypto > you do should not be an issue. That speed of hash is calculated from non-compress snapshot image, does not overlap with crc32. >=20 > Actually... >=20 > Is not it as simple as storing hash of hibernation image into NVRAM > and then verifying the hash matches the value in NVRAM on next > startup? No encryption needed.=20 >=20 > And that may even be useful for non-secure-boot people, as it ensures > you boot right image after resume, boot it just once, etc... >=20 > Pavel The HMAC approach will not encrypt, just put the key of HMAC to boottim= e variable.=20 If user doesn't enable UEFI secure boot, that's fine, the key of HMAC still cannot access in OS runtime.=20 If user enable UEFI secure boot, then that's better! Because all EFI file will signed by the manufacturers or OSVs to make sure the code is secure, will not pass the key to runtime. Thanks a lot! Joey Lee