[dm-crypt] Quick dm-crypt questions

[dm-crypt] Quick dm-crypt questions

[Cpp]

Hey,

I've got two questions abour dm-crypt/LUKS.

- Does dm-crypt/LUKS employ any RAM anti-forensics? In particular,
what is the danger of a master key being "burnt-in" into the RAM, if a
certain container is mounted for an extended period of time (a few
years)? Is the master key being periodically moved around in RAM (this
acts like a screen-saver or rather a RAM-saver) or does it reside at a
static location after the container is mounted?

- Is it possible to separate the LUKS header from the encrypted data?
Normally when a partition is luksFormat-ted it will generate a LUKS
header on that partition at the very beginning of space. But I was
wondering, if it's possible to have only the encrypted data on the
partition, and move the LUKS header somewhere else i.e. a file on a
USB stick?


Regards!

Re: [dm-crypt] Quick dm-crypt questions

[Milan Broz]

On 10/28/2014 10:15 AM, Cpp wrote:
> - Does dm-crypt/LUKS employ any RAM anti-forensics? In particular,
> what is the danger of a master key being "burnt-in" into the RAM, if a
> certain container is mounted for an extended period of time (a few
> years)? Is the master key being periodically moved around in RAM (this
> acts like a screen-saver or rather a RAM-saver) or does it reside at a
> static location after the container is mounted?

No. And because dm-crypt just block processing wrapper around kernel crypto API
it is more problem in cipher implementation there than in dmcrypt.
(IIRC the key is duplicated several times there because of parallel processing
on separate CPUs.)

But I do not believe this is real problem at all. BTW you can run
luksSuspend which should wipe all keys and reinstate them later, this will
"refresh" the memory area, at least partially.

(BTW If anyone have some reliable papers about this, please send a links, thanks.)

> - Is it possible to separate the LUKS header from the encrypted data?
> Normally when a partition is luksFormat-ted it will generate a LUKS
> header on that partition at the very beginning of space. But I was
> wondering, if it's possible to have only the encrypted data on the
> partition, and move the LUKS header somewhere else i.e. a file on a
> USB stick?

Yes. See --header option and "detached metadata" in cryptsetup man.

In this mode you should also use data payload offset to 0 bytes,
so the data device contains only encrypted data. (Or you can have random
data instead on LUKS header area on data device and use separate device
or file with LUKS header).

Milan

Re: [dm-crypt] Quick dm-crypt questions

[Arno Wagner]

On Tue, Oct 28, 2014 at 10:15:22 CET, Cpp wrote:
> Hey,
> 
> I've got two questions abour dm-crypt/LUKS.
> 
> - Does dm-crypt/LUKS employ any RAM anti-forensics? 

No. And not really needed anyways. This is for 
disk encryption, not for building a HSM (Hardware 
Security Module). Keys get wiped unmapping though.

> In particular,
> what is the danger of a master key being "burnt-in" into the RAM, if a
> certain container is mounted for an extended period of time (a few
> years)? Is the master key being periodically moved around in RAM (this
> acts like a screen-saver or rather a RAM-saver) or does it reside at a
> static location after the container is mounted?

That is potentially a concern with SRAM. DRAM may or may not be 
subject to similar effects, but they are not as easy to detect or 
use. Basically, you will have to lower refresh-rates until bits
fail and carefully monitor which ones will fail. Even that may 
not be conclusive at all, as cells are different. The
thing with SRAM is that both transistors in the flip-flop
are very similar, as they are very close together. An SRAM cell
may tend to come up in the state it has held for a long time.
A DRAM cell will always come up the same way, regardless of
what value it held, namely with capacitor empty.

AFAIK, the it is not even clear whether this still is an
issue in modern SRAMs. The only references I found on googeling
are describing this effect in the presence of a lot of
ionizing radiation for SRAM and I did not find a single
source for a similar effect for DRAM.

Here is a current reference on that, the literature may give
you more info:
https://repositories.tdl.org/ttu-ir/bitstream/handle/2346/58641/NAIR-DISSERTATION-2013.pdf

Note that the radiation doses this work looks at start at
100R and go up to 100kR. About 200R are reliably deadly for 
humans.

There are also devices like the DS3640 that claim to prevent this,
but it would not be the first time that a manufacturer advertises
"preventing" things that are not there in the first place:
http://www.maximintegrated.com/en/products/power/supervisors-voltage-monitors-sequencers/DS3640.html

BTW, you do _not_ move the key around to fight this. That
would not help. You complement all bits regularly instead.

> - Is it possible to separate the LUKS header from the encrypted data?
> Normally when a partition is luksFormat-ted it will generate a LUKS
> header on that partition at the very beginning of space. But I was
> wondering, if it's possible to have only the encrypted data on the
> partition, and move the LUKS header somewhere else i.e. a file on a
> USB stick?

See man-page and FAQ items 5.19 and 6.2. In the case of FLASH 
disks, it is actually a good idea to do so.

Arno
-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Quick dm-crypt questions

[Cpp]

I see, thanks for the detailed answer.

Personally I find this an interesting topic, and since I love to learn
and experiment, I bought a printed copy of Security Engineering (2nd
ed.) book by Ross Anderson. I'm currently on chapter 16 - Physical
Tamper Resistance, and in this chapter there is a paragraph on page
490, "How to hack a cryptoprocessor (4)", it says that "The better
third generation devices have RAM savers which function in much the
same way as screen savers; they move data around the RAM to prevent it
being burned in anywhere." This is where I got the idea to move the
key around in RAM.

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-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Summary.pdf

But if moving the data around is ineffective then perhaps I could do
something like this: Upon device power-on define two equal-length
(fixed length) buffers on the heap. Then generate a random number of
equal length from a cryptographic random number generator and write it
to both buffers. At periodic time intervals (can be configured to 1
hour, 2 hours, 12 hours, 24 hours, etc) generate another random number
like before, and XOR it into both buffers (buffer_1 ^= random_num;
buffer_2 ^= random_num;). Once the device receives the encryption key,
XOR it to *one* of the bufffers (buffer_1 ^= enc_key), and securely
overwrite the enc_key variable. At any point in the future when we
want to retrieve the key again, simply XOR both buffers to get it,
export it, and securely overwrite the variable that held the key.

Comments?

On 10/28/14, Arno Wagner <arno@wagner.name> wrote:
> On Tue, Oct 28, 2014 at 10:15:22 CET, Cpp wrote:
>> Hey,
>>
>> I've got two questions abour dm-crypt/LUKS.
>>
>> - Does dm-crypt/LUKS employ any RAM anti-forensics?
>
> No. And not really needed anyways. This is for
> disk encryption, not for building a HSM (Hardware
> Security Module). Keys get wiped unmapping though.
>
>> In particular,
>> what is the danger of a master key being "burnt-in" into the RAM, if a
>> certain container is mounted for an extended period of time (a few
>> years)? Is the master key being periodically moved around in RAM (this
>> acts like a screen-saver or rather a RAM-saver) or does it reside at a
>> static location after the container is mounted?
>
> That is potentially a concern with SRAM. DRAM may or may not be
> subject to similar effects, but they are not as easy to detect or
> use. Basically, you will have to lower refresh-rates until bits
> fail and carefully monitor which ones will fail. Even that may
> not be conclusive at all, as cells are different. The
> thing with SRAM is that both transistors in the flip-flop
> are very similar, as they are very close together. An SRAM cell
> may tend to come up in the state it has held for a long time.
> A DRAM cell will always come up the same way, regardless of
> what value it held, namely with capacitor empty.
>
> AFAIK, the it is not even clear whether this still is an
> issue in modern SRAMs. The only references I found on googeling
> are describing this effect in the presence of a lot of
> ionizing radiation for SRAM and I did not find a single
> source for a similar effect for DRAM.
>
> Here is a current reference on that, the literature may give
> you more info:
> https://repositories.tdl.org/ttu-ir/bitstream/handle/2346/58641/NAIR-DISSERTATION-2013.pdf
>
> Note that the radiation doses this work looks at start at
> 100R and go up to 100kR. About 200R are reliably deadly for
> humans.
>
> There are also devices like the DS3640 that claim to prevent this,
> but it would not be the first time that a manufacturer advertises
> "preventing" things that are not there in the first place:
> http://www.maximintegrated.com/en/products/power/supervisors-voltage-monitors-sequencers/DS3640.html
>
> BTW, you do _not_ move the key around to fight this. That
> would not help. You complement all bits regularly instead.
>
>> - Is it possible to separate the LUKS header from the encrypted data?
>> Normally when a partition is luksFormat-ted it will generate a LUKS
>> header on that partition at the very beginning of space. But I was
>> wondering, if it's possible to have only the encrypted data on the
>> partition, and move the LUKS header somewhere else i.e. a file on a
>> USB stick?
>
> See man-page and FAQ items 5.19 and 6.2. In the case of FLASH
> disks, it is actually a good idea to do so.
>
> Arno
> --
> 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
> "news" is "something that hardly ever happens." -- Bruce Schneier
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Quick dm-crypt questions

[Ralf Ramsauer]

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-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Summary.pdf

Yes, comments :-)

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.

But....

How do you want to realize the communication between the µC and you
Linux Box? Over Uart? (Uart communication can _easily_ be sniffed, so be
aware of that....)
Also don't forget to deactivate the JTAG interface. Otherwise the µC
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?

How does the key get to the µC?

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].

There are *so* many traps... Do you really think this is a good idea?

[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

Regards
  Ralf

Re: [dm-crypt] Quick dm-crypt questions

[Arno Wagner]

On Wed, Oct 29, 2014 at 10:24:13 CET, Cpp wrote:
> I see, thanks for the detailed answer.
> 
> Personally I find this an interesting topic, and since I love to learn
> and experiment, I bought a printed copy of Security Engineering (2nd
> ed.) book by Ross Anderson. I'm currently on chapter 16 - Physical
> Tamper Resistance, and in this chapter there is a paragraph on page
> 490, "How to hack a cryptoprocessor (4)", it says that "The better
> third generation devices have RAM savers which function in much the
> same way as screen savers; they move data around the RAM to prevent it
> being burned in anywhere." This is where I got the idea to move the
> key around in RAM.

While Ross Anderson does really good research and is well 
respected, that book is not a good book and in particular 
it is not an engineering book at all! 

As a collection of background stories, history, interesting
phenomena, it does fairly well, but as a guideline to solve
problems, it is a complete failure. 

As an example, moving the data around just means it getting 
burned in takes a little longer, even if you overwite the 
old data with crypto-randomness. The SRAM cells are succeptible
to usage-bias and that means only the complement of the key,
stored for the same time as the key, can erase the effect.
(That is for short storage time. For long ones, even that
 may not be enough.)

> 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-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Summary.pdf
> 
> But if moving the data around is ineffective then perhaps I could do
> something like this: Upon device power-on define two equal-length
> (fixed length) buffers on the heap. Then generate a random number of
> equal length from a cryptographic random number generator and write it
> to both buffers. At periodic time intervals (can be configured to 1
> hour, 2 hours, 12 hours, 24 hours, etc) generate another random number
> like before, and XOR it into both buffers (buffer_1 ^= random_num;
> buffer_2 ^= random_num;). Once the device receives the encryption key,
> XOR it to *one* of the bufffers (buffer_1 ^= enc_key), and securely
> overwrite the enc_key variable. At any point in the future when we
> want to retrieve the key again, simply XOR both buffers to get it,
> export it, and securely overwrite the variable that held the key.
> 
> Comments?

Do it simpler. Make one buffer and one flag, and periodically 
(once a minute or so), do the following:

buffer := not(buffer) // bitwise
flag := not (flag)    // logical.

That should be sufficient to prevent the burn-in effect.

Key recovery via

if (flag) {
  key := buffer;
} else {
  key := not(buffer) // bitwise
}

As to your overall security model: You need to ensure that 
an attacker only gets access to the uC and computer in 
an unpowered state, or you are screwed (for a resourceful 
attacker). An ATmega48A may even be known well to a gifted
amateur, as something pretty similar is in the Arduinos.
It might be exceptionally easy to cause this thing to go 
into a debug mode, and it may leak the data via TEMPEST.

But as a project to learn things, go for it.

Arno



> On 10/28/14, Arno Wagner <arno@wagner.name> wrote:
> > On Tue, Oct 28, 2014 at 10:15:22 CET, Cpp wrote:
> >> Hey,
> >>
> >> I've got two questions abour dm-crypt/LUKS.
> >>
> >> - Does dm-crypt/LUKS employ any RAM anti-forensics?
> >
> > No. And not really needed anyways. This is for
> > disk encryption, not for building a HSM (Hardware
> > Security Module). Keys get wiped unmapping though.
> >
> >> In particular,
> >> what is the danger of a master key being "burnt-in" into the RAM, if a
> >> certain container is mounted for an extended period of time (a few
> >> years)? Is the master key being periodically moved around in RAM (this
> >> acts like a screen-saver or rather a RAM-saver) or does it reside at a
> >> static location after the container is mounted?
> >
> > That is potentially a concern with SRAM. DRAM may or may not be
> > subject to similar effects, but they are not as easy to detect or
> > use. Basically, you will have to lower refresh-rates until bits
> > fail and carefully monitor which ones will fail. Even that may
> > not be conclusive at all, as cells are different. The
> > thing with SRAM is that both transistors in the flip-flop
> > are very similar, as they are very close together. An SRAM cell
> > may tend to come up in the state it has held for a long time.
> > A DRAM cell will always come up the same way, regardless of
> > what value it held, namely with capacitor empty.
> >
> > AFAIK, the it is not even clear whether this still is an
> > issue in modern SRAMs. The only references I found on googeling
> > are describing this effect in the presence of a lot of
> > ionizing radiation for SRAM and I did not find a single
> > source for a similar effect for DRAM.
> >
> > Here is a current reference on that, the literature may give
> > you more info:
> > https://repositories.tdl.org/ttu-ir/bitstream/handle/2346/58641/NAIR-DISSERTATION-2013.pdf
> >
> > Note that the radiation doses this work looks at start at
> > 100R and go up to 100kR. About 200R are reliably deadly for
> > humans.
> >
> > There are also devices like the DS3640 that claim to prevent this,
> > but it would not be the first time that a manufacturer advertises
> > "preventing" things that are not there in the first place:
> > http://www.maximintegrated.com/en/products/power/supervisors-voltage-monitors-sequencers/DS3640.html
> >
> > BTW, you do _not_ move the key around to fight this. That
> > would not help. You complement all bits regularly instead.
> >
> >> - Is it possible to separate the LUKS header from the encrypted data?
> >> Normally when a partition is luksFormat-ted it will generate a LUKS
> >> header on that partition at the very beginning of space. But I was
> >> wondering, if it's possible to have only the encrypted data on the
> >> partition, and move the LUKS header somewhere else i.e. a file on a
> >> USB stick?
> >
> > See man-page and FAQ items 5.19 and 6.2. In the case of FLASH
> > disks, it is actually a good idea to do so.
> >
> > Arno
> > --
> > 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
> > "news" is "something that hardly ever happens." -- Bruce Schneier
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Quick dm-crypt questions

[Arno Wagner]

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-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Summary.pdf
> 
> Yes, comments :-)
> 
> 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.
> 
> But....
> 
> How do you want to realize the communication between the µC 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 
disk encryption does not protect data while the system is running
and has the data decrypted. 

> Also don't forget to deactivate the JTAG interface. Otherwise the µC
> 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?
> 
> How does the key get to the µC?
> 
> 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].
> 
> 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
> 
> Regards
>   Ralf
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Quick dm-crypt questions

[Ralf Ramsauer]

On 29.10.2014 16:59, Arno Wagner wrote:
>> How do you want to realize the communication between the µC 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 
> disk encryption does not protect data while the system is running
> and has the data decrypted. 
>
Yes, exactly. So why putting such huge efforts on that using some
semi-professional setup that is probably condemned to failure?
Don't get me wrong, I also consider it as a nice teaching/learning
system, but don't think that it is more secure than before. I'd rather
believe in the opposite.

Why using such a setup at all? I don't get the benefits, I just see a
lot of further possible vulnerabilities.

And (for me) sniffing an UART connection or attaching some kind of
debugger is much easier than freezing the system down, applying black
vodoo magic and reading the bits back from frozen RAM :-)
As you said, Arno, AVRs are well-known hobbyist µCs.

Make a long story short: it is a nice teaching project in order to get
into all that stuff, but even if it seems to work and even if I would
have developed it on my own, I would not use it for protecting MY
private data.

Cheers
  Ralf

Re: [dm-crypt] Quick dm-crypt questions

[Ingo Schmitt]

On 10/29/14 15:59, * wrote:
> If an attacker has access on that level, they can probaly just do
> a memory-freeze attack or a fire-wire attack. Remember that 
> disk encryption does not protect data while the system is running
> and has the data decrypted. 

I thought, AES NI makes cold boot attacks almost impossible because
the master key will be hold in CPU's cache and not in system RAM.

Since I read that mail thread, I'm not sure about that anymore.

Pls enlighten me ;)

-- 
-- \__________________________________________________
ingo.schmitt@binarysignals.net - GnuPG ID: 0xAFD687D2 |
FP: 7418 77A6 4B59 AF90 4A11 1CCE 91C9 FF1B AFD6 87D2 |

Re: [dm-crypt] Quick dm-crypt questions

[Cpp]

Arno Wagner: Can you recommend any decent books on the subject of
physical tampering resistance and secure cryptographic hardware
design?

Thanks.

On 10/29/14, Arno Wagner <arno@wagner.name> wrote:
> 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-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Summary.pdf
>>
>> Yes, comments :-)
>>
>> 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.
>>
>> But....
>>
>> How do you want to realize the communication between the µC 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
> disk encryption does not protect data while the system is running
> and has the data decrypted.
>
>> Also don't forget to deactivate the JTAG interface. Otherwise the µC
>> 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?
>>
>> How does the key get to the µC?
>>
>> 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].
>>
>> 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
>>
>> Regards
>>   Ralf
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> 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
> "news" is "something that hardly ever happens." -- Bruce Schneier
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Quick dm-crypt questions

[Arno Wagner]

FAQ Item 6.10 should also apply to AES-NI, AFAIK. 
I do not have an AES-NI capable system though to
thest that.

I think this whole idea of storing keys in cache
was some demo at some conference, but is not fit for
practical deployment, as CPUs are too differtent.

Arno 



On Wed, Oct 29, 2014 at 16:46:10 CET, Ingo Schmitt wrote:
> 
> On 10/29/14 15:59, * wrote:
> > If an attacker has access on that level, they can probaly just do
> > a memory-freeze attack or a fire-wire attack. Remember that 
> > disk encryption does not protect data while the system is running
> > and has the data decrypted. 
> 
> I thought, AES NI makes cold boot attacks almost impossible because
> the master key will be hold in CPU's cache and not in system RAM.
> 
> Since I read that mail thread, I'm not sure about that anymore.
> 
> Pls enlighten me ;)
> 
> -- 
> -- \__________________________________________________
> ingo.schmitt@binarysignals.net - GnuPG ID: 0xAFD687D2 |
> FP: 7418 77A6 4B59 AF90 4A11 1CCE 91C9 FF1B AFD6 87D2 |
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Quick dm-crypt questions

[Arno Wagner]

Sorry, but no. I do not think any books on that topic exist.
The best you can do is to try research papers, but a lot of
what is used in practice will be secret and developed 
in-house.

For instances that are known to have failed in the past,
stories in Anderson's Book are likely a good place to 
start and then you can follow the literature references.
Youc an also look more specifically for articles on hacking
chip-cards, as that has been done by quite a few people.

But notice that nobody professional these days ever talks
about "tamper proof", it is always "tamper resistant", even
for secure microcontrollers. Too many past designs were
successfully attacked, often in ways that their designers
never expected. For exmaple, a "secure" Java card was 
successfully attacked by uploading a class file and then
holding it up to a light-bulb to heat it up. 

For how to do it right, you are mostly on your own. It is
not an accident that HSMs (Hardware Securty Modules) cost
$50'000 and upwards. Nobody really knows whether they are
worth that money, but the people that have tried to break
into them are not talking and are not even admiting that
they tried.

Gr"usse,
Arno


On Wed, Oct 29, 2014 at 16:53:08 CET, Cpp wrote:
> Arno Wagner: Can you recommend any decent books on the subject of
> physical tampering resistance and secure cryptographic hardware
> design?
> 
> Thanks.
> 
> On 10/29/14, Arno Wagner <arno@wagner.name> wrote:
> > 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-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Summary.pdf
> >>
> >> Yes, comments :-)
> >>
> >> 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.
> >>
> >> But....
> >>
> >> How do you want to realize the communication between the µC 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
> > disk encryption does not protect data while the system is running
> > and has the data decrypted.
> >
> >> Also don't forget to deactivate the JTAG interface. Otherwise the µC
> >> 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?
> >>
> >> How does the key get to the µC?
> >>
> >> 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].
> >>
> >> 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
> >>
> >> Regards
> >>   Ralf
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >
> > --
> > 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
> > "news" is "something that hardly ever happens." -- Bruce Schneier
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Quick dm-crypt questions

[Milan Broz]

On 10/29/2014 05:21 PM, Arno Wagner wrote:
> FAQ Item 6.10 should also apply to AES-NI, AFAIK. 
> I do not have an AES-NI capable system though to
> thest that.

I think AES-NI can help with some (cache) timing attack but
not with Cold boot.

> I think this whole idea of storing keys in cache
> was some demo at some conference, but is not fit for
> practical deployment, as CPUs are too differtent.

If you mean idea of frozen-cache, it's impact to performance is huge.

There is also TRESOR and loop-amnesia which tries
fix the cold boot problem.

(Just Google for frozen cache, tresor+aes or loop-amnesia for more info.)

But all is x86_64 only and there is a lot of problems
(the first one is that it is not in upstream kernel:-)

(And dmcrypt has still one copy of key in its structs,
so deploying such solution requires some changes here as well,
not trivial because of device-mapper table logic.)

Milan

Re: [dm-crypt] Quick dm-crypt questions

[Sven Eschenberg]

On Wed, October 29, 2014 17:50, Milan Broz wrote:
> On 10/29/2014 05:21 PM, Arno Wagner wrote:
>> FAQ Item 6.10 should also apply to AES-NI, AFAIK.
>> I do not have an AES-NI capable system though to
>> thest that.
>
> I think AES-NI can help with some (cache) timing attack but
> not with Cold boot.

How so? I mean, no matter what, the key needs to get loaded into a
register at some time (possible pipelining it through the cache first) and
will sooner or later vanish from the cache (or the cache might get
depleted) and needs to get loaded again. Keeping it in the cache is
difficult, and I don't see any hint that AES-NI uses internal registers
(unadressable ones) to keep the key there once it is loaded.

And then there's still the possibility of debug interfaces (i.e. HALT+DUMP).

>
>> I think this whole idea of storing keys in cache
>> was some demo at some conference, but is not fit for
>> practical deployment, as CPUs are too differtent.
>
> If you mean idea of frozen-cache, it's impact to performance is huge.
>
> There is also TRESOR and loop-amnesia which tries
> fix the cold boot problem.

Didn't tresor try to keep the key within registers?

Regards

-Sven

>
> (Just Google for frozen cache, tresor+aes or loop-amnesia for more info.)
>
> But all is x86_64 only and there is a lot of problems
> (the first one is that it is not in upstream kernel:-)
>
> (And dmcrypt has still one copy of key in its structs,
> so deploying such solution requires some changes here as well,
> not trivial because of device-mapper table logic.)
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>