Let's say I have a secret program processing secret data that I don't want anyone else to get their hands on. I supply the hardware this will run on (say, a conventional desktop PC), however it will run in an unsecure location. I can specify some restrictions on the conditions of the hardware (e.g. it is not to be touched or interferred with in any way).
If tampering is detected, destroying a HDD (or multiple HDDs/SSDs) quickly enough that data can't be recovered (or the destruction process stopped) seems pretty difficult.
What if the drives are encrypted with a key stored on a flash chip? There's a battery-backed circuit that maintains a high voltage across a capacitor not far from flash chip. When tampering is detected the HV is discharged across the flash chip. Could much be recovered from the chip? Obviously just trying to hook it up in another circuit would be futile. I'm guessing any other forensic techniques would also fail, because a large chunk of the internal structure of the IC would be destroyed.
Tampering would be detected by, for example: temperatures out of range, excessive vibration, orientation, motion detection in the enclosure and changes in resistance/capacitance/inductance of lengths of wire running around the outside of the enclosure. The tamper circuit would also be triggered if mains power is lost and the battery power drops below the threshold required to maintain the HV.
There are other issues to consider, like caching of the encryption key in RAM and the CPU cache. They'd have to be destroyed too. Just switching off and assuming the data's lost leaves one open to attacks where the chip is quickly cooled (reducing the 'decay' of the volatile storage), extracted, then dumped. Swap space would also have to be encrypted.
Can anyone see any potentially viable attacks against this approach? (Not counting rubber-hose cryptanalysis - there's a big difference between spending a few thousand dollars trying to reverse engineer an electrical system vs. kidnapping and torturing someone.)
> If tampering is detected, destroying a HDD (or multiple HDDs/SSDs) quickly
> enough that data can't be recovered (or the destruction process stopped) seems
> pretty difficult.
One option, if you have a UPS and/or can visit the site, is to just use normal full-disk encryption and have it prompt for a password in order to boot the system. If it detects any tampering it just does an immediate hard reset and then the entire disk is inaccessible until someone comes by and types in the key again.
Of course this does mean you'd have to visit the site to type in your key after a power outage, but it does avoid the problems of figuring out how to destroy a local non-volatile copy of the key, e.g. in flash as you describe.
There is of course one flaw in your plan - you say you're specifying that the hardware is not to be touched, but then you want to protect against people touching it? Maybe you do want a secure area after all :-) Especially if you want to protect against military style cooling attacks...
I think it is impossible to completely ensure your data's safety if physical access to the machine is possible. Maybe you could bury the machine at the bottom of a very deep hole? By the time anyone has managed to dig it out your vibration sensors would've picked up the intrusion and you could've erased every last bit in every storage medium many times over ;-)
I have used flash chips over a spi bus, these usaly take in the order of
1-3 seconds to do a full erase depending on manufacturer and size.
Maybe SSD could do something similar?
Hovo
On Monday, July 30, 2012, Brendan C / theban wrote:
> Let's say I have a secret program processing secret data that I don't want
> anyone else to get their hands on. I supply the hardware this will run on
> (say, a conventional desktop PC), however it will run in an unsecure
> location. I can specify some restrictions on the conditions of the
> hardware (e.g. it is not to be touched or interferred with in any way).
> If tampering is detected, destroying a HDD (or multiple HDDs/SSDs) quickly
> enough that data can't be recovered (or the destruction process stopped)
> seems pretty difficult.
> What if the drives are encrypted with a key stored on a flash chip?
> There's a battery-backed circuit that maintains a high voltage across a
> capacitor not far from flash chip. When tampering is detected the HV is
> discharged across the flash chip. Could much be recovered from the chip?
> Obviously just trying to hook it up in another circuit would be futile.
> I'm guessing any other forensic techniques would also fail, because a
> large chunk of the internal structure of the IC would be destroyed.
> Tampering would be detected by, for example: temperatures out of range,
> excessive vibration, orientation, motion detection in the enclosure and
> changes in resistance/capacitance/inductance of lengths of wire running
> around the outside of the enclosure. The tamper circuit would also be
> triggered if mains power is lost and the battery power drops below the
> threshold required to maintain the HV.
> There are other issues to consider, like caching of the encryption key in
> RAM and the CPU cache. They'd have to be destroyed too. Just switching
> off and assuming the data's lost leaves one open to attacks where the chip
> is quickly cooled (reducing the 'decay' of the volatile storage),
> extracted, then dumped.
> Swap space would also have to be encrypted.
> Can anyone see any potentially viable attacks against this approach?
> (Not counting rubber-hose cryptanalysis - there's a big difference between
> spending a few thousand dollars trying to reverse engineer an electrical
> system vs. kidnapping and torturing someone.)
> - Brendan C / theban
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/hackerspace_brisbane/-/l5uMgteqIO0J.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com<javascript:_e({}, 'cvml', 'hackerspace_brisbane@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com <javascript:_e({},
> 'cvml', 'hackerspace_brisbane%2Bunsubscribe@googlegroups.com');>.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> I have used flash chips over a spi bus, these usaly take in the order of 1-3 seconds to do a full erase depending on manufacturer and size.
> Maybe SSD could do something similar?
> Hovo
> On Monday, July 30, 2012, Brendan C / theban wrote:
> Purely hypothetical situation:
> Let's say I have a secret program processing secret data that I don't want anyone else to get their hands on. I supply the hardware this will run on (say, a conventional desktop PC), however it will run in an unsecure location. I can specify some restrictions on the conditions of the hardware (e.g. it is not to be touched or interferred with in any way).
> If tampering is detected, destroying a HDD (or multiple HDDs/SSDs) quickly enough that data can't be recovered (or the destruction process stopped) seems pretty difficult.
> What if the drives are encrypted with a key stored on a flash chip? There's a battery-backed circuit that maintains a high voltage across a capacitor not far from flash chip. When tampering is detected the HV is discharged across the flash chip. Could much be recovered from the chip? Obviously just trying to hook it up in another circuit would be futile. I'm guessing any other forensic techniques would also fail, because a large chunk of the internal structure of the IC would be destroyed.
> Tampering would be detected by, for example: temperatures out of range, excessive vibration, orientation, motion detection in the enclosure and changes in resistance/capacitance/inductance of lengths of wire running around the outside of the enclosure. The tamper circuit would also be triggered if mains power is lost and the battery power drops below the threshold required to maintain the HV.
> There are other issues to consider, like caching of the encryption key in RAM and the CPU cache. They'd have to be destroyed too. Just switching off and assuming the data's lost leaves one open to attacks where the chip is quickly cooled (reducing the 'decay' of the volatile storage), extracted, then dumped.
> Swap space would also have to be encrypted.
> Can anyone see any potentially viable attacks against this approach?
> (Not counting rubber-hose cryptanalysis - there's a big difference between spending a few thousand dollars trying to reverse engineer an electrical system vs. kidnapping and torturing someone.)
> - Brendan C / theban
> -- > You received this message because you are subscribed to the Google Groups "hackerspace_brisbane" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/hackerspace_brisbane/-/l5uMgteqIO0J.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com.
> To unsubscribe from this group, send email to hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hackerspace_brisbane?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com.
> To unsubscribe from this group, send email to hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hackerspace_brisbane?hl=en.
Erasing an SSD properly would take a while. Just ask anyone who had one of
the slightly older ones that didn't support TRIM when they ran out of free
blocks (random hangs when writing while old blocks were erased to make room
for new). You'd also want to be sure that it actually erased the chip too
(as some manufacturers have a habit of cheating when it comes to erasing
stuff).
If you're not worried about price of replacing it, thought about using
thermite? Just put it around the chips (key flash & SSD storage) and set it
off when you're 'worried'. Of course, there's OH&S concerns here.
Might even be useful after you hit it with a high voltage (eg: 5kv) and
'fry' the chips (possibly even use the same spark to start the thermite).
All you need would be a tiny package that covers the chips and possibly put
a simple trigger system across the power rail of the chips that will only
fire on a high voltage.
BTW: If you're using a spinning disk, you could wind a big electromagnet
around it and just continuously fire the magnet in pules to wipe the disk.
After that, as Joel suggests, physically damage the disk. If you had access
to a clean-room, I'd remove the cover and put the 'tamper device' that
destroys the disk inside the drive, as then you don't have to puncture the
top cover as well. Will of course void your warranty. ;)
I cannot speak for SSD's, but from what I was taught many years ago was
that the only way to ensure data being recoverable from a disk, is to
either melt it or granulate it ( so termite would do the trick nicely :) )
Drilling holes in the platter will slow someone down and add to the cost of
recovery, but will not prevent them (with significant time and money)
getting back the data, and having it encrypted on there simply adds to the
cost again.
On 31 July 2012 08:56, Stuart Young <cef...@gmail.com> wrote:
> Erasing an SSD properly would take a while. Just ask anyone who had one of
> the slightly older ones that didn't support TRIM when they ran out of free
> blocks (random hangs when writing while old blocks were erased to make room
> for new). You'd also want to be sure that it actually erased the chip too
> (as some manufacturers have a habit of cheating when it comes to erasing
> stuff).
> If you're not worried about price of replacing it, thought about using
> thermite? Just put it around the chips (key flash & SSD storage) and set it
> off when you're 'worried'. Of course, there's OH&S concerns here.
> Might even be useful after you hit it with a high voltage (eg: 5kv) and
> 'fry' the chips (possibly even use the same spark to start the thermite).
> All you need would be a tiny package that covers the chips and possibly
> put a simple trigger system across the power rail of the chips that will
> only fire on a high voltage.
> BTW: If you're using a spinning disk, you could wind a big electromagnet
> around it and just continuously fire the magnet in pules to wipe the disk.
> After that, as Joel suggests, physically damage the disk. If you had access
> to a clean-room, I'd remove the cover and put the 'tamper device' that
> destroys the disk inside the drive, as then you don't have to puncture the
> top cover as well. Will of course void your warranty. ;)
> --
> Stuart Young (aka Cefiar)
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
Thermite is tricky to ignite and will burn buildings down if over done. the best thing to use is an electrically triggered syringe full of strong acid that gets injected into the platters. Melt or burn or granulate .... that's the only way to be sure. Of course... if you are actually doing this then you are clearly using the wrong approach. There is always an easier way... Buzz
Luke Irwin <bujinka...@gmail.com> wrote: >I cannot speak for SSD's, but from what I was taught many years ago was >that the only way to ensure data being recoverable from a disk, is to >either melt it or granulate it ( so termite would do the trick nicely :) ) >Drilling holes in the platter will slow someone down and add to the cost of >recovery, but will not prevent them (with significant time and money) >getting back the data, and having it encrypted on there simply adds to the >cost again.
>On 31 July 2012 08:56, Stuart Young <cef...@gmail.com> wrote:
>> Erasing an SSD properly would take a while. Just ask anyone who had one of >> the slightly older ones that didn't support TRIM when they ran out of free >> blocks (random hangs when writing while old blocks were erased to make room >> for new). You'd also want to be sure that it actually erased the chip too >> (as some manufacturers have a habit of cheating when it comes to erasing >> stuff).
>> If you're not worried about price of replacing it, thought about using >> thermite? Just put it around the chips (key flash & SSD storage) and set it >> off when you're 'worried'. Of course, there's OH&S concerns here.
>> Might even be useful after you hit it with a high voltage (eg: 5kv) and >> 'fry' the chips (possibly even use the same spark to start the thermite).
>> All you need would be a tiny package that covers the chips and possibly >> put a simple trigger system across the power rail of the chips that will >> only fire on a high voltage.
>> BTW: If you're using a spinning disk, you could wind a big electromagnet >> around it and just continuously fire the magnet in pules to wipe the disk. >> After that, as Joel suggests, physically damage the disk. If you had access >> to a clean-room, I'd remove the cover and put the 'tamper device' that >> destroys the disk inside the drive, as then you don't have to puncture the >> top cover as well. Will of course void your warranty. ;)
>> -- >> Stuart Young (aka Cefiar)
>> -- >> You received this message because you are subscribed to the Google Groups >> "hackerspace_brisbane" group. >> To post to this group, send email to hackerspace_brisbane@googlegroups.com >> . >> To unsubscribe from this group, send email to >> hackerspace_brisbane+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/hackerspace_brisbane?hl=en.
>-- >You received this message because you are subscribed to the Google Groups "hackerspace_brisbane" group. >To post to this group, send email to hackerspace_brisbane@googlegroups.com. >To unsubscribe from this group, send email to hackerspace_brisbane+unsubscribe@googlegroups.com. >For more options, visit this group at http://groups.google.com/group/hackerspace_brisbane?hl=en.
On Tue, Jul 31, 2012 at 9:20 AM, Buzz <davidb...@gmail.com> wrote:
> Thermite is tricky to ignite and will burn buildings down if over done.
> the best thing to use is an electrically triggered syringe full of strong
> acid that gets injected into the platters. Melt or burn or granulate ....
> that's the only way to be sure.
> Of course... if you are actually doing this then you are clearly using the
> wrong approach. There is always an easier way...
> Buzz
> >I cannot speak for SSD's, but from what I was taught many years ago was
> >that the only way to ensure data being recoverable from a disk, is to
> >either melt it or granulate it ( so termite would do the trick nicely :)
> )
> >Drilling holes in the platter will slow someone down and add to the cost
> of
> >recovery, but will not prevent them (with significant time and money)
> >getting back the data, and having it encrypted on there simply adds to the
> >cost again.
> >On 31 July 2012 08:56, Stuart Young <cef...@gmail.com> wrote:
> >> Erasing an SSD properly would take a while. Just ask anyone who had one
> of
> >> the slightly older ones that didn't support TRIM when they ran out of
> free
> >> blocks (random hangs when writing while old blocks were erased to make
> room
> >> for new). You'd also want to be sure that it actually erased the chip
> too
> >> (as some manufacturers have a habit of cheating when it comes to erasing
> >> stuff).
> >> If you're not worried about price of replacing it, thought about using
> >> thermite? Just put it around the chips (key flash & SSD storage) and
> set it
> >> off when you're 'worried'. Of course, there's OH&S concerns here.
> >> Might even be useful after you hit it with a high voltage (eg: 5kv) and
> >> 'fry' the chips (possibly even use the same spark to start the
> thermite).
> >> All you need would be a tiny package that covers the chips and possibly
> >> put a simple trigger system across the power rail of the chips that will
> >> only fire on a high voltage.
> >> BTW: If you're using a spinning disk, you could wind a big electromagnet
> >> around it and just continuously fire the magnet in pules to wipe the
> disk.
> >> After that, as Joel suggests, physically damage the disk. If you had
> access
> >> to a clean-room, I'd remove the cover and put the 'tamper device' that
> >> destroys the disk inside the drive, as then you don't have to puncture
> the
> >> top cover as well. Will of course void your warranty. ;)
> >> --
> >> Stuart Young (aka Cefiar)
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "hackerspace_brisbane" group.
> >> To post to this group, send email to
> hackerspace_brisbane@googlegroups.com
> >> .
> >> To unsubscribe from this group, send email to
> >> hackerspace_brisbane+unsubscribe@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> >--
> >You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> >To post to this group, send email to
> hackerspace_brisbane@googlegroups.com.
> >To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> >For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> You could just make it a dumb terminal and keep the data in a remote
> location and just cut the link if detected.
> On Tue, Jul 31, 2012 at 9:20 AM, Buzz <davidb...@gmail.com> wrote:
>> Thermite is tricky to ignite and will burn buildings down if over done.
>> the best thing to use is an electrically triggered syringe full of strong
>> acid that gets injected into the platters. Melt or burn or granulate ....
>> that's the only way to be sure.
>> Of course... if you are actually doing this then you are clearly using
>> the wrong approach. There is always an easier way...
>> Buzz
>> >I cannot speak for SSD's, but from what I was taught many years ago was
>> >that the only way to ensure data being recoverable from a disk, is to
>> >either melt it or granulate it ( so termite would do the trick nicely
>> :) )
>> >Drilling holes in the platter will slow someone down and add to the cost
>> of
>> >recovery, but will not prevent them (with significant time and money)
>> >getting back the data, and having it encrypted on there simply adds to
>> the
>> >cost again.
>> >On 31 July 2012 08:56, Stuart Young <cef...@gmail.com> wrote:
>> >> Erasing an SSD properly would take a while. Just ask anyone who had
>> one of
>> >> the slightly older ones that didn't support TRIM when they ran out of
>> free
>> >> blocks (random hangs when writing while old blocks were erased to make
>> room
>> >> for new). You'd also want to be sure that it actually erased the chip
>> too
>> >> (as some manufacturers have a habit of cheating when it comes to
>> erasing
>> >> stuff).
>> >> If you're not worried about price of replacing it, thought about using
>> >> thermite? Just put it around the chips (key flash & SSD storage) and
>> set it
>> >> off when you're 'worried'. Of course, there's OH&S concerns here.
>> >> Might even be useful after you hit it with a high voltage (eg: 5kv) and
>> >> 'fry' the chips (possibly even use the same spark to start the
>> thermite).
>> >> All you need would be a tiny package that covers the chips and possibly
>> >> put a simple trigger system across the power rail of the chips that
>> will
>> >> only fire on a high voltage.
>> >> BTW: If you're using a spinning disk, you could wind a big
>> electromagnet
>> >> around it and just continuously fire the magnet in pules to wipe the
>> disk.
>> >> After that, as Joel suggests, physically damage the disk. If you had
>> access
>> >> to a clean-room, I'd remove the cover and put the 'tamper device' that
>> >> destroys the disk inside the drive, as then you don't have to puncture
>> the
>> >> top cover as well. Will of course void your warranty. ;)
>> >> --
>> >> Stuart Young (aka Cefiar)
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "hackerspace_brisbane" group.
>> >> To post to this group, send email to
>> hackerspace_brisbane@googlegroups.com
>> >> .
>> >> To unsubscribe from this group, send email to
>> >> hackerspace_brisbane+unsubscribe@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/hackerspace_brisbane?hl=en.
>> >--
>> >You received this message because you are subscribed to the Google
>> Groups "hackerspace_brisbane" group.
>> >To post to this group, send email to
>> hackerspace_brisbane@googlegroups.com.
>> >To unsubscribe from this group, send email to
>> hackerspace_brisbane+unsubscribe@googlegroups.com.
>> >For more options, visit this group at
>> http://groups.google.com/group/hackerspace_brisbane?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "hackerspace_brisbane" group.
>> To post to this group, send email to
>> hackerspace_brisbane@googlegroups.com.
>> To unsubscribe from this group, send email to
>> hackerspace_brisbane+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
On Tue, Jul 31, 2012 at 9:04 AM, Luke Irwin <bujinka...@gmail.com> wrote:
> I cannot speak for SSD's, but from what I was taught many years ago was
> that the only way to ensure data being recoverable from a disk, is to
> either melt it or granulate it ( so termite would do the trick nicely :) )
> Drilling holes in the platter will slow someone down and add to the cost
> of recovery, but will not prevent them (with significant time and money)
> getting back the data, and having it encrypted on there simply adds to the
> cost again.
> On 31 July 2012 08:56, Stuart Young <cef...@gmail.com> wrote:
>> Erasing an SSD properly would take a while. Just ask anyone who had one
>> of the slightly older ones that didn't support TRIM when they ran out of
>> free blocks (random hangs when writing while old blocks were erased to make
>> room for new). You'd also want to be sure that it actually erased the chip
>> too (as some manufacturers have a habit of cheating when it comes to
>> erasing stuff).
>> If you're not worried about price of replacing it, thought about using
>> thermite? Just put it around the chips (key flash & SSD storage) and set it
>> off when you're 'worried'. Of course, there's OH&S concerns here.
>> Might even be useful after you hit it with a high voltage (eg: 5kv) and
>> 'fry' the chips (possibly even use the same spark to start the thermite).
>> All you need would be a tiny package that covers the chips and possibly
>> put a simple trigger system across the power rail of the chips that will
>> only fire on a high voltage.
>> BTW: If you're using a spinning disk, you could wind a big electromagnet
>> around it and just continuously fire the magnet in pules to wipe the disk.
>> After that, as Joel suggests, physically damage the disk. If you had access
>> to a clean-room, I'd remove the cover and put the 'tamper device' that
>> destroys the disk inside the drive, as then you don't have to puncture the
>> top cover as well. Will of course void your warranty. ;)
>> --
>> Stuart Young (aka Cefiar)
>> --
>> You received this message because you are subscribed to the Google Groups
>> "hackerspace_brisbane" group.
>> To post to this group, send email to
>> hackerspace_brisbane@googlegroups.com.
>> To unsubscribe from this group, send email to
>> hackerspace_brisbane+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
The missing parts are: *How valuable is the data?* And: *What are the consequences of loosing control of the data?* Everything hinges around those questions.
If it's worth multiple millions, and the consequences of loosing the data may result in death (of someone you care about) you might consider hiring a team from Blackwater to stand guard 24/7. If we are talking thousands or 10's of thousands, then you might want to put the server inside a robust tamper proof safe. :)
Your general concept of encrypting the data and blowing away the key when you need to wipe is defiantly the way to go. Its by far the fastest way to destroy any size of data. What you want though, is properly architected security, built into the data storage itself, not relying on an OS with all the OS vagary as an attack surface.
If you were one of my customers I would be suggesting your security budget was proportional to the value of the data you are trying to protect. But seeing as you're (probably) not one of my customers, and are looking for suggestions here, I'm guessing that your budget is limited. - What about deploying the application/data on a non-standard, proprietary architecture that uses whole device encryption and blows away the key when a) the password is not correct, and b) the battery is removed. What off the shelf platform matches that? [see link below] :)
Solution Idea: What about an iPad locked in a booby trapped safe? :) If anyone is able to physically hack into the safe, and then physically hack into the iPad all without disconnecting the battery, and then recovering the key, and then using the key to decrypt the memory.... Well, I think it would be easier to break into your place of business, or kidnap you at that point.
> The missing parts are: *How valuable is the data?* And: *What are
> the consequences of loosing control of the data?* Everything hinges
> around those questions.
> If it's worth multiple millions, and the consequences of loosing the data
> may result in death (of someone you care about) you might consider hiring a
> team from Blackwater to stand guard 24/7. If we are talking thousands or
> 10's of thousands, then you might want to put the server inside a robust
> tamper proof safe. :)
> Your general concept of encrypting the data and blowing away the key when
> you need to wipe is defiantly the way to go. Its by far the fastest way to
> destroy any size of data. What you want though, is properly
> architected security, built into the data storage itself, not relying on an
> OS with all the OS vagary as an attack surface.
> If you were one of my customers I would be suggesting your security budget
> was proportional to the value of the data you are trying to protect. But
> seeing as you're (probably) not one of my customers, and are looking for
> suggestions here, I'm guessing that your budget is limited. - What about
> deploying the application/data on a non-standard, proprietary architecture
> that uses whole device encryption and blows away the key when a) the
> password is not correct, and b) the battery is removed. What off the
> shelf platform matches that? [see link below] :)
> Solution Idea: What about an iPad locked in a booby trapped safe? :) If
> anyone is able to physically hack into the safe, and then physically hack
> into the iPad all without disconnecting the battery, and
> then recovering the key, and then using the key to decrypt the memory....
> Well, I think it would be easier to break into your place of business,
> or kidnap you at that point.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
-- --
Ben Cooper
Executive Director
Cooper Anderson Holdings PTY LTD
M: 0410411301
E: bcoo...@cooperanderson.com.au
W: http://www.cooperanderson.com.au
> On Tue, Jul 31, 2012 at 1:22 PM, MikeGChambers <mike.ker...@gmail.com>wrote:
>> Cool, I love this question.
>> The missing parts are: *How valuable is the data?* And: *What are
>> the consequences of loosing control of the data?* Everything hinges
>> around those questions.
>> If it's worth multiple millions, and the consequences of loosing the data
>> may result in death (of someone you care about) you might consider hiring a
>> team from Blackwater to stand guard 24/7. If we are talking thousands or
>> 10's of thousands, then you might want to put the server inside a robust
>> tamper proof safe. :)
>> Your general concept of encrypting the data and blowing away the key when
>> you need to wipe is defiantly the way to go. Its by far the fastest way to
>> destroy any size of data. What you want though, is properly
>> architected security, built into the data storage itself, not relying on an
>> OS with all the OS vagary as an attack surface.
>> If you were one of my customers I would be suggesting
>> your security budget was proportional to the value of the data you are
>> trying to protect. But seeing as you're (probably) not one of my
>> customers, and are looking for suggestions here, I'm guessing that your
>> budget is limited. - What about deploying the application/data on a
>> non-standard, proprietary architecture that uses whole device encryption
>> and blows away the key when a) the password is not correct, and b) the
>> battery is removed. What off the shelf platform matches that? [see link
>> below] :)
>> Solution Idea: What about an iPad locked in a booby trapped safe? :) If
>> anyone is able to physically hack into the safe, and then physically hack
>> into the iPad all without disconnecting the battery, and
>> then recovering the key, and then using the key to decrypt the memory....
>> Well, I think it would be easier to break into your place of business,
>> or kidnap you at that point.
>> To post to this group, send email to
>> hackerspace_brisbane@googlegroups.com.
>> To unsubscribe from this group, send email to
>> hackerspace_brisbane+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> --
> --
> Ben Cooper
> Executive Director
> Cooper Anderson Holdings PTY LTD
> M: 0410411301
> E: bcoo...@cooperanderson.com.au
> W: http://www.cooperanderson.com.au
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
On Tuesday, July 31, 2012 1:51:34 PM UTC+10, Ben Cooper wrote:
> Dead link btw.
> On Tue, Jul 31, 2012 at 1:22 PM, MikeGChambers <mike.ker...@gmail.com>wrote:
>> Cool, I love this question.
>> The missing parts are: *How valuable is the data?* And: *What are >> the consequences of loosing control of the data?* Everything hinges >> around those questions.
>> If it's worth multiple millions, and the consequences of loosing the data >> may result in death (of someone you care about) you might consider hiring a >> team from Blackwater to stand guard 24/7. If we are talking thousands or >> 10's of thousands, then you might want to put the server inside a robust >> tamper proof safe. :)
>> Your general concept of encrypting the data and blowing away the key when >> you need to wipe is defiantly the way to go. Its by far the fastest way to >> destroy any size of data. What you want though, is properly >> architected security, built into the data storage itself, not relying on an >> OS with all the OS vagary as an attack surface.
>> If you were one of my customers I would be suggesting >> your security budget was proportional to the value of the data you are >> trying to protect. But seeing as you're (probably) not one of my >> customers, and are looking for suggestions here, I'm guessing that your >> budget is limited. - What about deploying the application/data on a >> non-standard, proprietary architecture that uses whole device encryption >> and blows away the key when a) the password is not correct, and b) the >> battery is removed. What off the shelf platform matches that? [see link >> below] :)
>> Solution Idea: What about an iPad locked in a booby trapped safe? :) If >> anyone is able to physically hack into the safe, and then physically hack >> into the iPad all without disconnecting the battery, and >> then recovering the key, and then using the key to decrypt the memory.... >> Well, I think it would be easier to break into your place of business, >> or kidnap you at that point.
>> To post to this group, send email to >> hackerspace_brisbane@googlegroups.com. >> To unsubscribe from this group, send email to >> hackerspace_brisbane+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> -- > -- > Ben Cooper > Executive Director > Cooper Anderson Holdings PTY LTD > M: 0410411301 > E: bcoo...@cooperanderson.com.au > W: http://www.cooperanderson.com.au
Sorry but I think I thought of a somewhat simple solution.
I had this entire conversation some years back with a friend
so I've heard hundreds of idea's.
It's not completely permemant but may be good enough
in australia.
Don't worry about destroying the hard drive platter. Simply
destroy the controller chips on the HDD controller board.
The easiest way to do this is reverse the polarity. Swap
12v and Ground, and Ground and 12v from a custom
controller. The controller board is likely to be 3.3v or 5v.
It won't survive a reverse polarity 12v shock.
(I just tested overvoltage to controllers this week so I
know it works)
> Sorry but I think I thought of a somewhat simple solution.
> I had this entire conversation some years back with a friend
> so I've heard hundreds of idea's.
> It's not completely permemant but may be good enough
> in australia.
> Don't worry about destroying the hard drive platter. Simply
> destroy the controller chips on the HDD controller board.
> The easiest way to do this is reverse the polarity. Swap
> 12v and Ground, and Ground and 12v from a custom
> controller. The controller board is likely to be 3.3v or 5v.
> It won't survive a reverse polarity 12v shock.
> (I just tested overvoltage to controllers this week so I
> know it works)
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> Don't worry about destroying the hard drive platter. Simply
> destroy the controller chips on the HDD controller board.
Meaning you could swap the controller board from a good drive of the same model to then recover the data?
> The easiest way to do this is reverse the polarity. Swap
> 12v and Ground, and Ground and 12v from a custom
> controller. The controller board is likely to be 3.3v or 5v.
> It won't survive a reverse polarity 12v shock.
Maybe if you burn out the motor it would mean you'd have to move the platters into a new drive, but still...
I think simply having the PC forget the encryption key is much quicker, easier, and also reversible if it happens by accident.
On Tue, Jul 31, 2012 at 4:06 PM, tjhowse <tjho...@gmail.com> wrote:
> Replace logic board with one from an identical drive. Read data. Profit.
> On 31 July 2012 16:03, David Lyon <david.lyon.preissh...@gmail.com> wrote:
>> Hi guys,
>> Sorry but I think I thought of a somewhat simple solution.
>> I had this entire conversation some years back with a friend
>> so I've heard hundreds of idea's.
>> It's not completely permemant but may be good enough
>> in australia.
>> Don't worry about destroying the hard drive platter. Simply
>> destroy the controller chips on the HDD controller board.
>> The easiest way to do this is reverse the polarity. Swap
>> 12v and Ground, and Ground and 12v from a custom
>> controller. The controller board is likely to be 3.3v or 5v.
>> It won't survive a reverse polarity 12v shock.
>> (I just tested overvoltage to controllers this week so I
>> know it works)
>> --
>> You received this message because you are subscribed to the Google Groups
>> "hackerspace_brisbane" group.
>> To post to this group, send email to
>> hackerspace_brisbane@googlegroups.com.
>> To unsubscribe from this group, send email to
>> hackerspace_brisbane+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
On Tue, Jul 31, 2012 at 4:03 PM, David Lyon <david.lyon.preissh...@gmail.com
> wrote:
> Hi guys,
> Sorry but I think I thought of a somewhat simple solution.
> I had this entire conversation some years back with a friend
> so I've heard hundreds of idea's.
> It's not completely permemant but may be good enough
> in australia.
> Don't worry about destroying the hard drive platter. Simply
> destroy the controller chips on the HDD controller board.
Doesn't work. I blew a controller in a HDD a few years back, just bought a
replacement controller from a US ebay store, install and off you go.
I've also had more serious failures that have been almost 100% recovered by
spending a few hundred $$$ with a data recovery service. There's a group
ion Melbounre with a class <whatever> clean room and they can do amazing
things if the data is sufficiently important and you have enough money to
spend.
Physical destruction of the media is your only option IMO.
I remember seeing somewhere, several years ago, a device that connected
inline on the ide ribbon.. it encrypted the stream flowing through it... pc
only saw a clean data, and the drive only ever saw encrypted data.. and it
had the key provided to it, by a usb style connector...
When powering up with usb connected, it would retrieve the key and store it
in volatile memory so you could unplug the usb and walk away, knowing that
if the power went off, then everything was encrypted and safe...
There might be a market in building something like this for sata drives,
and building it with the ability to destroy stored keys/melt the usb fob to
slag as required.
To clarify, this isn't for a real application. I was thinking that if I
one day I commercialise a project I'm working on how I would protect
the Intellectual Property (beyond the very basic measures commonly in use).
To continue with the example project: it searches and manipulates nodes in
a (mathematical) graph. Lots of RAM needed, mostly CPU bound.
> There is of course one flaw in your plan - you say you're specifying that
the hardware is not to be touched, but then you want to protect against
people touching it?
What I mean is I can specify that it's not to be touched, but I can't trust
the other party to do what they're told. If they don't follow the
specifications and it self-destructs the onus is on them for not meeting
the specifications they agreed to.
> Maybe you do want a secure area after all :-)
Good point. I would effectively be making a secure area inside the
enclosure.
> Especially if you want to protect against military style cooling
attacks...
I've seen videos of some pretty low-tech cooling attacks. E.g. upside down
"can of air"/duster spray on the RAM, which is quickly put into another
machine that boots into a custom program that dumps the RAM contents onto
storage.
> I think it is impossible to completely ensure your data's safety if
physical access to the machine is possible.
Agreed. I'm just trying to make it really hard. Infeasibly hard.
> Maybe you could bury the machine at the bottom of a very deep hole? By
the time anyone has managed to dig it out your vibration sensors would've
picked up the intrusion and you could've erased every last bit in every
storage medium many times over ;-)
I was thinking of a desktop machine in an office or workshop environment,
but yes, a deep hole would buy some time. Though then I'd need to
guarantee much more time than I would to just destroy a flash chip.
> I have used flash chips over a spi bus, these usaly take in the order of
1-3 seconds to do a full erase depending on manufacturer and size.
My understanding is even a full erase of flash / EEPROM memory leaves
residual traces, that I imagine could be detected by microprobing. Similar
to residual magnetic fields on a magnetic HDD. The cells ideally have
binary states, but like all digital circuits are analogue forced into one
state or another. If there was a 0->1->0 transition, we might actually be
able to read 0.1. That's why it's advised to write over your data with
random garbage multiple times; even if residuals could be detected, they'd
be garbage.
> Install your hard drives in a machine that can crush or punch them.
I've considered that. It seems much harder to adequately destroy a HDD
than it does to destroy a flash chip.
> Erasing an SSD properly would take a while.
Agreed.
> If you're not worried about price of replacing it,
I'm potentially cooking the RAM and CPU to prevent cooling attacks. Adding
a HDD to the bill, if it's to protect thousands of $ of IP, seems pretty
reasonable.
> Will of course void your warranty. ;)
We're posting on a hackerspace mailing list. I assumed it was mandatory to
void a warranty ;)
> thought about using thermite? .... Of course, there's OH&S concerns here.
Yeah, I'd say thermite is too dangerous for most situations.
@Lemming: I could only watch the first 15 mins of that, but it looked like
they were skimming over the "destroy the encryption key" method because it
wasn't as cool as the other methods.
Destroying the HDD controller is obfuscation at best (unless of course it
has onboard encryption). Given you can get a data recovery company to
replace (and presumably recalibrate) the electronics for a few hundred $, I
don't really consider that to be secure, just inconvenient for an attacker.
@MikeGChambers: A pro, eh?
> What you want though, is properly architected security, built into the
data storage itself, not relying on an OS with all the OS vagary as an
attack surface.
You're suggesting that using ddcrypt on Linux (or similar) to handle the
drive encryption would be less secure, than say a SATA controller that
handled all the crypto directly? The reasoning being it's comparitively
easy to crack an OS than to remotely get control of a SATA controller?
(Presumably because the only feasible way would be to first crack the OS)
Did you suggest an iPad in a safe because it has encryption at the data
storage layer? That would be an interesting solution to my example if I
didn't need so much CPU grunt.
i recall some usb keys with a little twist, they used volitile memory
instead of flash with a small battery backup, when you plugged it it what
would happen is it would come up as a serial port and if you had the
program that manages it installed it would ask for a password, if you
entered the wrong password 3 times it would simply cut power to the memmory
and all the data would be lost, it also has a tampering proof case where it
was sealed with a positive pressure if you punctured the case the battery
would be disconnected and again data lost, i wish i could remember the
company name
On Tue, Jul 31, 2012 at 5:33 PM, Brendan Carmichael <
> To clarify, this isn't for a real application. I was thinking that if I
> one day I commercialise a project I'm working on how I would protect
> the Intellectual Property (beyond the very basic measures commonly in use).
> To continue with the example project: it searches and manipulates nodes in
> a (mathematical) graph. Lots of RAM needed, mostly CPU bound.
> > There is of course one flaw in your plan - you say you're specifying
> that the hardware is not to be touched, but then you want to protect
> against people touching it?
> What I mean is I can specify that it's not to be touched, but I can't
> trust the other party to do what they're told. If they don't follow the
> specifications and it self-destructs the onus is on them for not meeting
> the specifications they agreed to.
> > Maybe you do want a secure area after all :-)
> Good point. I would effectively be making a secure area inside the
> enclosure.
> > Especially if you want to protect against military style cooling
> attacks...
> I've seen videos of some pretty low-tech cooling attacks. E.g. upside
> down "can of air"/duster spray on the RAM, which is quickly put into
> another machine that boots into a custom program that dumps the RAM
> contents onto storage.
> > I think it is impossible to completely ensure your data's safety if
> physical access to the machine is possible.
> Agreed. I'm just trying to make it really hard. Infeasibly hard.
> > Maybe you could bury the machine at the bottom of a very deep hole? By
> the time anyone has managed to dig it out your vibration sensors would've
> picked up the intrusion and you could've erased every last bit in every
> storage medium many times over ;-)
> I was thinking of a desktop machine in an office or workshop environment,
> but yes, a deep hole would buy some time. Though then I'd need to
> guarantee much more time than I would to just destroy a flash chip.
> > I have used flash chips over a spi bus, these usaly take in the order of
> 1-3 seconds to do a full erase depending on manufacturer and size.
> My understanding is even a full erase of flash / EEPROM memory leaves
> residual traces, that I imagine could be detected by microprobing. Similar
> to residual magnetic fields on a magnetic HDD. The cells ideally have
> binary states, but like all digital circuits are analogue forced into one
> state or another. If there was a 0->1->0 transition, we might actually be
> able to read 0.1. That's why it's advised to write over your data with
> random garbage multiple times; even if residuals could be detected, they'd
> be garbage.
> > Install your hard drives in a machine that can crush or punch them.
> I've considered that. It seems much harder to adequately destroy a HDD
> than it does to destroy a flash chip.
> > Erasing an SSD properly would take a while.
> Agreed.
> > If you're not worried about price of replacing it,
> I'm potentially cooking the RAM and CPU to prevent cooling attacks.
> Adding a HDD to the bill, if it's to protect thousands of $ of IP, seems
> pretty reasonable.
> > Will of course void your warranty. ;)
> We're posting on a hackerspace mailing list. I assumed it was mandatory
> to void a warranty ;)
> > thought about using thermite? .... Of course, there's OH&S concerns here.
> Yeah, I'd say thermite is too dangerous for most situations.
> @Lemming: I could only watch the first 15 mins of that, but it looked
> like they were skimming over the "destroy the encryption key" method
> because it wasn't as cool as the other methods.
> Destroying the HDD controller is obfuscation at best (unless of course it
> has onboard encryption). Given you can get a data recovery company to
> replace (and presumably recalibrate) the electronics for a few hundred $, I
> don't really consider that to be secure, just inconvenient for an attacker.
> @MikeGChambers: A pro, eh?
> > What you want though, is properly architected security, built into the
> data storage itself, not relying on an OS with all the OS vagary as an
> attack surface.
> You're suggesting that using ddcrypt on Linux (or similar) to handle the
> drive encryption would be less secure, than say a SATA controller that
> handled all the crypto directly? The reasoning being it's comparitively
> easy to crack an OS than to remotely get control of a SATA controller?
> (Presumably because the only feasible way would be to first crack the OS)
> Did you suggest an iPad in a safe because it has encryption at the data
> storage layer? That would be an interesting solution to my example if I
> didn't need so much CPU grunt.
> --
> You received this message because you are subscribed to the Google Groups
> "hackerspace_brisbane" group.
> To post to this group, send email to hackerspace_brisbane@googlegroups.com
> .
> To unsubscribe from this group, send email to
> hackerspace_brisbane+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hackerspace_brisbane?hl=en.
> To clarify, this isn't for a real application. I was thinking that if I
> one day I commercialise a project I'm working on how I would protect
> the Intellectual Property (beyond the very basic measures commonly in
> use). To continue with the example project: it searches and manipulates
> nodes in a (mathematical) graph. Lots of RAM needed, mostly CPU bound.
I would've thought the best way would be a patent, and a wide open system that's easy to copy.
When someone copies it, steals all your customers and starts making huge profits, you just come along and claim huge royalties for use of your patent.