FPGA on a DIMM module, performing encryption

Hi group.

I'm about to embark on a final year project for my University course,
and since I have a reputation for too-ambitious projects, thought that
I'd ask how 'straightfoward' this task would be here, before I decide
finally.

My main idea at the moment is an encrypting DIMM module, intended to
protect against 'cold boot' attacks, and the scenario that an attacker
is presented with a freshly-turned-off machine with some juicy secret
still in a DIMM module, which they can then remove, throw in to some
socket, and dump.

My intent is to XOR-encode memory (using a suitably large key and some
yet-to-be-thought-up scheduling algo to prevent against predictable
null plaintext weaknesses) in an FPGA on-the-fly before writing/
reading main DRAM. I was planning to implement 'proper' strong crypto,
but don't really think it's practical to encrypt/decrypt data fast
enough.

I'm planning on working a generation or two behind current technology,
with either 133MHz SDR or DDR parts. I haven't worked with DRAM at
this low a level before, but am hoping that I can fit CL3 DRAMs to my
module, instruct the BIOS to use CL2 (perhaps through some bodging of
the SPD), and use the resultant 'spare' cycle to do my XOR'ing. Does
this sound plausible, or would it only really be practical/possible to
use faster DRAMS to do as I describe?

Another thought I've had is to tell the BIOS that I'm running
registered DIMM modules, and generate the necessary 'spare' clock that
way, with the register being in my FPGA logic, and using a DLL/PLL to
ensure that I've got enough time to select a key, and xor it (I don't
envision needing more than 2 clocks - say 4 for safety). Does this
sound more plausible?

Would the only 'practical' way to do all this be to use DDR DRAM chips
(and associated power/etc cleverness) on an SDR board? I don't like
that idea, it sounds scary :)

Also, I'm kind of apprehensive about laying out a board for this. I'm
pretty inexperienced in PCB design, but have the University library
(not to mention their EE department staff!) to help, so I figure it
shouldn't be too bad. How complex a board design would this be,
subjectively speaking?

And my last question - I'm thinking of using a Spartan 3 for this. I
can't think of any reason it'd require anything beefier such as a
Virtex - can any of you? I'm fairly neutral in terms of vender A or X,
but more experienced with X parts. Having said that, I'm not doing
anything terribly complex in terms of logic (am I?)

Thanks for reading, and yes, I should be talking to the Uni instead of
the Internet about this - but term hasn't started yet, and I'm trying
to be really organised this year...

- Alan H.

<randomdude@gmail.com> wrote in message 
news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com...
> My main idea at the moment is an encrypting DIMM module, intended to
> protect against 'cold boot' attacks, and the scenario that an attacker
> is presented with a freshly-turned-off machine with some juicy secret
> still in a DIMM module, which they can then remove, throw in to some
> socket, and dump.

Perhaps the first order of business is to establish that this is a viable 
attack.  Can someone really do that? SDRAM refresh cycles are on the order 
of <10 usec, otherwise data would be lost. I would think much simpler and 
more severe "attacks" would be available once you gained physical control of 
the machine. Cutting out the living and still beating heart idea tops them 
all in complexity.

On Sep 1, 4:52=A0am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> <randomd...@gmail.com> wrote in message
>
> news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com...
>
> > My main idea at the moment is an encrypting DIMM module, intended to
> > protect against 'cold boot' attacks, and the scenario that an attacker
> > is presented with a freshly-turned-off machine with some juicy secret
> > still in a DIMM module, which they can then remove, throw in to some
> > socket, and dump.
>
> Perhaps the first order of business is to establish that this is a viable
> attack. =A0Can someone really do that? SDRAM refresh cycles are on the or=
der
> of <10 usec, otherwise data would be lost. I would think much simpler and
> more severe "attacks" would be available once you gained physical control=
 of
> the machine. Cutting out the living and still beating heart idea tops the=
m
> all in complexity.

Yup, apparently so. See http://citp.princeton.edu/memory/ :)

<randomdude@gmail.com> wrote in message 
news:b24b1f24-0ecb-4eb1-8193-26bdc61a1ff9@73g2000hsx.googlegroups.com...
On Sep 1, 4:52 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> <randomd...@gmail.com> wrote in message
>
> news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com...
>
> > My main idea at the moment is an encrypting DIMM module, intended to
> > protect against 'cold boot' attacks, and the scenario that an attacker
> > is presented with a freshly-turned-off machine with some juicy secret
> > still in a DIMM module, which they can then remove, throw in to some
> > socket, and dump.
>
> Perhaps the first order of business is to establish that this is a viable
> attack. Can someone really do that? SDRAM refresh cycles are on the order
> of <10 usec, otherwise data would be lost. I would think much simpler and
> more severe "attacks" would be available once you gained physical control 
> of
> the machine. Cutting out the living and still beating heart idea tops them
> all in complexity.

Yup, apparently so. See http://citp.princeton.edu/memory/ :)

---------
Thanks.

In regards your original question, if viability encompasses usability, the 
huge power footprint is a problem. Simpler, less intrusive solutions are 
likely possible. For example, drawing down the residual charge in the memory 
cells will also render their old contents inaccessible.

On Sun, 31 Aug 2008 15:58:54 -0700 (PDT), randomdude@gmail.com wrote:

>Hi group.
>
>I'm about to embark on a final year project for my University course,
>and since I have a reputation for too-ambitious projects, thought that
>I'd ask how 'straightfoward' this task would be here, before I decide
>finally.
>
>My main idea at the moment is an encrypting DIMM module, intended to
>protect against 'cold boot' attacks, and the scenario that an attacker
>is presented with a freshly-turned-off machine with some juicy secret
>still in a DIMM module, which they can then remove, throw in to some
>socket, and dump.
>
>My intent is to XOR-encode memory (using a suitably large key and some
>yet-to-be-thought-up scheduling algo to prevent against predictable
>null plaintext weaknesses) in an FPGA on-the-fly before writing/
>reading main DRAM. I was planning to implement 'proper' strong crypto,
>but don't really think it's practical to encrypt/decrypt data fast
>enough.

Maybe if you were encrypt the address instead of the data, that might give you a little more time to
handle things. The end result should be pretty much the same.
It also means you can treat reads and writes the same, and have far fewer signals to intercept,
simplifying your PCB layout task.

..of course if the aim is to counter removal, maybe a much simpler approach would be something that
detects removal and erases the memory. 

On 1 sept, 12:28, Mike Harrison <m...@whitewing.co.uk> wrote:
> On Sun, 31 Aug 2008 15:58:54 -0700 (PDT), randomd...@gmail.com wrote:
> >Hi group.
>
> >I'm about to embark on a final year project for my University course,
> >and since I have a reputation for too-ambitious projects, thought that
> >I'd ask how 'straightfoward' this task would be here, before I decide
> >finally.
>
> >My main idea at the moment is an encrypting DIMM module, intended to
> >protect against 'cold boot' attacks, and the scenario that an attacker
> >is presented with a freshly-turned-off machine with some juicy secret
> >still in a DIMM module, which they can then remove, throw in to some
> >socket, and dump.
>
> >My intent is to XOR-encode memory (using a suitably large key and some
> >yet-to-be-thought-up scheduling algo to prevent against predictable
> >null plaintext weaknesses) in an FPGA on-the-fly before writing/
> >reading main DRAM. I was planning to implement 'proper' strong crypto,
> >but don't really think it's practical to encrypt/decrypt data fast
> >enough.
>
> Maybe if you were encrypt the address instead of the data, that might give you a little more time to
> handle things. The end result should be pretty much the same.
> It also means you can treat reads and writes the same, and have far fewer signals to intercept,
> simplifying your PCB layout task.
>
> ..of course if the aim is to counter removal, maybe a much simpler approach would be something that
> detects removal and erases the memory.

really bad suggestion ;)
the bus width is 8 bytes, now we also need handle burst writes so we
only
can change (crypt) adress on the max burst size boundary, leaving
LARGE
portions of the data unmodified, larger then is needed to hold credit
card
numbers and other information..

erasing the memory is also not an option, because the erase circuitry
will be disabled by the attacker and it takes too long anyway

and the data encryption must also be done right or it is of no use
if the key is not hold in volatile self desctructable memory, and the
module HAS to deal with tampering, means it has to be powered
on ALL the time. wrong :)
the module has to GENERATE new keys each time it is powered on
and it has to DESTRUCT that key on tamper attempt or power change
so it must be alive just a little after power removal.

security above entry level isnt so easy anymore at all

Antti
PS the RAM retention is really an issue, I have used ram dumps
done AFTER power off cycle for debugging myself, usually with
0 bad bits captured.

On Sep 1, 8:21=A0am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> <randomd...@gmail.com> wrote in message
>
> news:b24b1f24-0ecb-4eb1-8193-26bdc61a1ff9@73g2000hsx.googlegroups.com...
> On Sep 1, 4:52 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
>
>
> > <randomd...@gmail.com> wrote in message
>
> >news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com..=
.
>
> > > My main idea at the moment is an encrypting DIMM module, intended to
> > > protect against 'cold boot' attacks, and the scenario that an attacke=
r
> > > is presented with a freshly-turned-off machine with some juicy secret
> > > still in a DIMM module, which they can then remove, throw in to some
> > > socket, and dump.
>
> > Perhaps the first order of business is to establish that this is a viab=
le
> > attack. Can someone really do that? SDRAM refresh cycles are on the ord=
er
> > of <10 usec, otherwise data would be lost. I would think much simpler a=
nd
> > more severe "attacks" would be available once you gained physical contr=
ol
> > of
> > the machine. Cutting out the living and still beating heart idea tops t=
hem
> > all in complexity.
>
> Yup, apparently so. Seehttp://citp.princeton.edu/memory/:)
>
> ---------
> Thanks.
>
> In regards your original question, if viability encompasses usability, th=
e
> huge power footprint is a problem. Simpler, less intrusive solutions are
> likely possible. For example, drawing down the residual charge in the mem=
ory
> cells will also render their old contents inaccessible.

Hum, thanks - I hadn't thought of it in terms of power budget (I guess
that shows my inexperience!). I'll look in to that in depth. What kind
of less-intrusive solutions do you mean, though? How would you lower
the residual power in each cell? The obvious way it to overwrite RAM
with zeros on power-on, but this would be mitigated by transplanting
the DIMM in question to another machine (or a custom board).

On Sep 1, 11:04 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> and the data encryption must also be done right or it is of no use
> if the key is not hold in volatile self desctructable memory, and the
> module HAS to deal with tampering, means it has to be powered
> on ALL the time. wrong :)
> the module has to GENERATE new keys each time it is powered on
> and it has to DESTRUCT that key on tamper attempt or power change
> so it must be alive just a little after power removal.
> Antti

My plan was to store the key in the FPGA - block RAM, flipflops, or
some such - where it would be destroyed at poweron by the GSR pulse,
and would cause an attacker to need to disassemble the FPGA itself and
use some electron wizardry at the die level. Am I right in this
belief?
Actually, my plan was to use a custom BIOS (ie, openBIOS/coreboot) to
send a user-supplied key to the module on each poweron, from keyboard
or some removable device. This does entail some extra work, though,
and your suggestion of generating a key on each boot sounds a lot
better - I can whack some 'pretty random number source' chip on the
module and use it as a key source. Thanks!

<randomdude@gmail.com> wrote in message 
news:61f17dbd-b201-4ea9-b646-49590a772e5a@73g2000hsx.googlegroups.com...
On Sep 1, 8:21 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> <randomd...@gmail.com> wrote in message
>
> news:b24b1f24-0ecb-4eb1-8193-26bdc61a1ff9@73g2000hsx.googlegroups.com...
> On Sep 1, 4:52 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
>
>
> > <randomd...@gmail.com> wrote in message
>
> >news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com...
>
> > > My main idea at the moment is an encrypting DIMM module, intended to
> > > protect against 'cold boot' attacks, and the scenario that an attacker
> > > is presented with a freshly-turned-off machine with some juicy secret
> > > still in a DIMM module, which they can then remove, throw in to some
> > > socket, and dump.
>
> > Perhaps the first order of business is to establish that this is a 
> > viable
> > attack. Can someone really do that? SDRAM refresh cycles are on the 
> > order
> > of <10 usec, otherwise data would be lost. I would think much simpler 
> > and
> > more severe "attacks" would be available once you gained physical 
> > control
> > of
> > the machine. Cutting out the living and still beating heart idea tops 
> > them
> > all in complexity.
>
> Yup, apparently so. Seehttp://citp.princeton.edu/memory/:)
>
> ---------
> Thanks.
>
> In regards your original question, if viability encompasses usability, the
> huge power footprint is a problem. Simpler, less intrusive solutions are
> likely possible. For example, drawing down the residual charge in the 
> memory
> cells will also render their old contents inaccessible.

Hum, thanks - I hadn't thought of it in terms of power budget (I guess
that shows my inexperience!). I'll look in to that in depth. What kind
of less-intrusive solutions do you mean, though? How would you lower
the residual power in each cell? The obvious way it to overwrite RAM
with zeros on power-on, but this would be mitigated by transplanting
the DIMM in question to another machine (or a custom board).

-------
I don't know if it can be done, whether entirely externally or even with 
help on the memory chip. Speed and power draw, particularly for portables, 
are visible and of concern to end users. Just document the possibility, and 
what you found while researching alternatives.

On Sep 1, 9:42=A0pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> <randomd...@gmail.com> wrote in message
>
> news:61f17dbd-b201-4ea9-b646-49590a772e5a@73g2000hsx.googlegroups.com...
> On Sep 1, 8:21 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
>
>
> > <randomd...@gmail.com> wrote in message
>
> >news:b24b1f24-0ecb-4eb1-8193-26bdc61a1ff9@73g2000hsx.googlegroups.com...
> > On Sep 1, 4:52 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
> > > <randomd...@gmail.com> wrote in message
>
> > >news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com=
...
>
> > > > My main idea at the moment is an encrypting DIMM module, intended t=
o
> > > > protect against 'cold boot' attacks, and the scenario that an attac=
ker
> > > > is presented with a freshly-turned-off machine with some juicy secr=
et
> > > > still in a DIMM module, which they can then remove, throw in to som=
e
> > > > socket, and dump.
>
> > > Perhaps the first order of business is to establish that this is a
> > > viable
> > > attack. Can someone really do that? SDRAM refresh cycles are on the
> > > order
> > > of <10 usec, otherwise data would be lost. I would think much simpler
> > > and
> > > more severe "attacks" would be available once you gained physical
> > > control
> > > of
> > > the machine. Cutting out the living and still beating heart idea tops
> > > them
> > > all in complexity.
>
> > Yup, apparently so. Seehttp://citp.princeton.edu/memory/:)
>
> > ---------
> > Thanks.
>
> > In regards your original question, if viability encompasses usability, =
the
> > huge power footprint is a problem. Simpler, less intrusive solutions ar=
e
> > likely possible. For example, drawing down the residual charge in the
> > memory
> > cells will also render their old contents inaccessible.
>
> Hum, thanks - I hadn't thought of it in terms of power budget (I guess
> that shows my inexperience!). I'll look in to that in depth. What kind
> of less-intrusive solutions do you mean, though? How would you lower
> the residual power in each cell? The obvious way it to overwrite RAM
> with zeros on power-on, but this would be mitigated by transplanting
> the DIMM in question to another machine (or a custom board).
>
> -------
> I don't know if it can be done, whether entirely externally or even with
> help on the memory chip.

Do you mean from a technical perspective?

> Speed

I don't suppose you could be any more specific? Is my assertion that I
could use the extra spare clock (in a scenario where the system
expects CL3 memory and the boar duses CL2) incorrect? If not, surely I
could just tell the system that the DIMM is registered and do things
that way? I couldn't find any way for the memory modules to 'stall'
the host system, so I'm not sure how my approach could slow system
speed. Or perhaps you mean that getting my FPGA design to hit timing
would be difficult/impossible?

> and power draw, particularly for portables,
> are visible and of concern to end users.

But I think there's a subset of those users that place more worry over
the security of their data. What kind of ballpark power demands do you
envision? Are my rough 'guestimates' of 'low tens to a couple hundred
mW' way out?

<randomdude@gmail.com> wrote in message 
news:9212d27d-bd7c-479e-bacf-72345456c9bb@c58g2000hsc.googlegroups.com...
On Sep 1, 9:42 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> <randomd...@gmail.com> wrote in message
>
> news:61f17dbd-b201-4ea9-b646-49590a772e5a@73g2000hsx.googlegroups.com...
> On Sep 1, 8:21 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
>
>
> > <randomd...@gmail.com> wrote in message
>
> >news:b24b1f24-0ecb-4eb1-8193-26bdc61a1ff9@73g2000hsx.googlegroups.com...
> > On Sep 1, 4:52 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
> > > <randomd...@gmail.com> wrote in message
>
> > >news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com...
>
> > > > My main idea at the moment is an encrypting DIMM module, intended to
> > > > protect against 'cold boot' attacks, and the scenario that an 
> > > > attacker
> > > > is presented with a freshly-turned-off machine with some juicy 
> > > > secret
> > > > still in a DIMM module, which they can then remove, throw in to some
> > > > socket, and dump.
>
> > > Perhaps the first order of business is to establish that this is a
> > > viable
> > > attack. Can someone really do that? SDRAM refresh cycles are on the
> > > order
> > > of <10 usec, otherwise data would be lost. I would think much simpler
> > > and
> > > more severe "attacks" would be available once you gained physical
> > > control
> > > of
> > > the machine. Cutting out the living and still beating heart idea tops
> > > them
> > > all in complexity.
>
> > Yup, apparently so. Seehttp://citp.princeton.edu/memory/:)
>
> > ---------
> > Thanks.
>
> > In regards your original question, if viability encompasses usability, 
> > the
> > huge power footprint is a problem. Simpler, less intrusive solutions are
> > likely possible. For example, drawing down the residual charge in the
> > memory
> > cells will also render their old contents inaccessible.
>
> Hum, thanks - I hadn't thought of it in terms of power budget (I guess
> that shows my inexperience!). I'll look in to that in depth. What kind
> of less-intrusive solutions do you mean, though? How would you lower
> the residual power in each cell? The obvious way it to overwrite RAM
> with zeros on power-on, but this would be mitigated by transplanting
> the DIMM in question to another machine (or a custom board).
>
> -------
> I don't know if it can be done, whether entirely externally or even with
> help on the memory chip.

Do you mean from a technical perspective?

> Speed

I don't suppose you could be any more specific? Is my assertion that I
could use the extra spare clock (in a scenario where the system
expects CL3 memory and the boar duses CL2) incorrect? If not, surely I
could just tell the system that the DIMM is registered and do things
that way? I couldn't find any way for the memory modules to 'stall'
the host system, so I'm not sure how my approach could slow system
speed. Or perhaps you mean that getting my FPGA design to hit timing
would be difficult/impossible?

----------
The only thing I had in mind was your CL2 to CL3. It's a noticeable 
throughput hit.

> and power draw, particularly for portables,
> are visible and of concern to end users.

But I think there's a subset of those users that place more worry over
the security of their data. What kind of ballpark power demands do you
envision? Are my rough 'guestimates' of 'low tens to a couple hundred
mW' way out?

-------
Don't let me distract you. You're sniffing the right directions, and I 
haven't spent nearly as much time thinking about this as you.