From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Wed, 29 Oct 2014 15:59:01 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-44-24.dclient.hispeed.ch [77.57.44.24]) by v6.tansi.org (Postfix) with ESMTPA id 7BE9234FA001 for ; Wed, 29 Oct 2014 15:59:01 +0100 (CET) Date: Wed, 29 Oct 2014 15:59:01 +0100 From: Arno Wagner Message-ID: <20141029145900.GC11970@tansi.org> References: <20141028111351.GA23722@tansi.org> <5450C274.6020909@ramses-pyramidenbau.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <5450C274.6020909@ramses-pyramidenbau.de> Subject: Re: [dm-crypt] Quick dm-crypt questions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Wed, Oct 29, 2014 at 11:33:24 CET, Ralf Ramsauer wrote: > On 29.10.2014 11:24, Cpp wrote: > > The thing is I planned to use a microcontroller to store an encryption > > key in its RAM, and I see the device uses SRAM, so this might be a > > problem? > > http://www.atmel.com/Images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega= 48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Summary.pdf >=20 > Yes, comments :-) >=20 > First of all: are you going to store the Masterkey or the Passphrase / > Keyfile which is used for key derivation? > If you're going to store the master key, you don't need Luks at all, > this would also be a solution for your detached-header problem. >=20 > But.... >=20 > How do you want to realize the communication between the =B5C and you > Linux Box? Over Uart? (Uart communication can _easily_ be sniffed, so be > aware of that....) If an attacker has access on that level, they can probaly just do a memory-freeze attack or a fire-wire attack. Remember that=20 disk encryption does not protect data while the system is running and has the data decrypted.=20 > Also don't forget to deactivate the JTAG interface. Otherwise the =B5C > could get debugged... And don't forget to set the correct FUSE bits > (disallow reading / writing from / to flash / EPROM memory, ....) > And did you know, that CPU operations can be reconstructed by small > fluctuations in current[1]? How do you want to solve this issue? >=20 > How does the key get to the =B5C? >=20 > Aah, almost forgot to mention: you talked about to use a RNG on your AVR > to move the key around. RNG on AVR? From where do you get your entropy? > I don't know much about this project, but maybe this helps you [2]. >=20 > There are *so* many traps... Do you really think this is a good idea? I think this is mostly intended as a project to learn. As such it should do well. But do not expet this to be secure against a competent attacker. Arno > [1] http://en.wikipedia.org/wiki/Power_analysis > [2] http://www.das-labor.org/wiki/AVR-Crypto-Lib // > http://www.das-labor.org/wiki/AVR-Crypto-Lib#PRNGs >=20 > Regards > Ralf > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of=20 "news" is "something that hardly ever happens." -- Bruce Schneier