Re: [TSCM-L] {1409} Re: {1406} Harddisk destroy in les then 30 sec ? from James Greenwold on 2007-03-22 (file.mbox)

From: James Greenwold <b..._at_charter.net>
Date: Thu, 22 Mar 2007 08:27:34 -0600

>From - Sat Mar 02 00:57:18 2024
Received: by 10.36.33.8 with SMTP id g8mr231479nzg.1174535128924;
 Wed, 21 Mar 2007 20:45:28 -0700 (PDT)
Return-Path: <reginal..._at_hotmail.com>
Received: from bay0-omc2-s26.bay0.hotmail.com (bay0-omc2-s26.bay0.hotmail.com [65.54.246.162])
 by mx.google.com with ESMTP id y6si1092529nzg.2007.03.21.20.45.28;
 Wed, 21 Mar 2007 20:45:28 -0700 (PDT)
Received-SPF: pass (google.com: domain of reginal..._at_hotmail.com designates 65.54.246.162 as permitted sender)
Received: from hotmail.com ([207.46.9.216]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668);
 Wed, 21 Mar 2007 20:45:28 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
 Wed, 21 Mar 2007 20:45:28 -0700
Message-ID: <BAY120-F8FFC888C3B93643F98CC6846B0_at_phx.gbl>
Received: from 207.46.9.251 by by120fd.bay120.hotmail.msn.com with HTTP;
 Thu, 22 Mar 2007 03:45:24 GMT
X-Originating-IP: [74.106.212.207]
X-Originating-Email: [reginal..._at_hotmail.com]
X-Sender: reginal..._at_hotmail.com
In-Reply-To: <0703212251240.30508_at_somehost.domainz.com>
From: "Reginald Curtis" <reginal..._at_hotmail.com>
To: TSCM-L2006_at_googlegroups.com
Cc: garya_..._at_hotmail.com
Bcc:
Subject: RE: [TSCM-L] {1410} Re: Harddisk destroy in les then 30 sec ?
Date: Thu, 22 Mar 2007 03:45:24 +0000
Mime-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 22 Mar 2007 03:45:28.0125 (UTC) FILETIME=[88200ED0:01C76C34]
Return-Path: reginal..._at_hotmail.com

<html><div style='background-color:'> 
.............................
Just a comment on the explosive route. I believe something could be cons=
tructed fairly easily using the explosive bolt sytem which is built into&nb=
sp;many walls, doors and windows when/where rapid egress may be required. T=
hese are similar to the system that is/was used on aircraft ejection s=
eats. These are electically fired and the last I heard, extremely safe.&nbs=
p; I don't think that acquiring them would be a problem, provided someone o=
n the project was suitably certified.
<DIV>
<DIV>Reg Curtis/VE9RWC</DIV><=
/DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c=
6e5 2px solid; MARGIN-RIGHT: 0px">
<HR color=#a0c6e5 SIZE=1>
From: Thomas Shaddack <t..._at_shaddack.mauriceward.com> Reply=
-To: TSCM-..._at_googlegroups.com To: TSCM-L Professionals List &=
lt;TSC..._at_googlegroups.com> Subject: [TSCM-L] {1410} Re: Hardd=
isk destroy in les then 30 sec ? Date: Thu, 22 Mar 2007 03:16:12 =
+0100 (CET) > > >The JMA's solutions are potentially =
unreliable. There has to be a >considerably fine mechanics involved, =
and the hard drive has to be opened, >potentially contaminating the p=
latters with dust and gravely impairing >reliability. > >=
 > >First some flashy bangy testosterony ideas. > >=
 > >If I remember correctly, a standard procedure for disk dest=
roying in the >field when a unit is about to be captured by the enemy=
is shooting through >the disks with tactically important
information from a handgun. > >A way to quite thoroughly destro=
y the disk plates and render them >unreadable against any sane budget=
level could be therefore multiple >perforations inflicted by eg. a p=
oint-blank shotgun blast. > >I hereby propose an arrangement of=
several (4 to 8?) shotgun shells, >electrically triggered (independe=
ntly, for higher reliability), located in >a circle over the disk pla=
tes in steel pipes of a suitable length >(calculate or test for the b=
est spread pattern) acting as short barrels. >Once triggered, a storm=
of metal pieces goes through the plates, shredding >the magnetic lay=
er and deforming the plates. > >The enclosure has to be specifi=
ed from sufficiently bullet-resistant >material (armor? concrete?) so=
there is no chance of the projectiles to >escape. There also has to=

be a set of reliable interlocks blocking the >firing circuits if the =
enclosure is opened, to ensure safety of the >operator and eventual c=
ontractors. This is also why I would caution >against using mechanica=
l firing system with springs. > > > >A variant of t=
he construction may use a shaped charge that cuts the disk >plates to=
pieces in under a microsecond. Again, we do not have to open the >di=
sk itself (as the charge will cut through the housing), therefore we do =
>not impair its reliability nor warranty. Interlocks are again strongly<=
BR>>advised for. A suitable explosive with required long-term stability =
and >guaranteed reliability is however unlikely to be found on open m=
arket. > > > >A speculative possibility is flooding=
the disk with an acid or other >corrosive chemical that dissolves
the magnetic layer. The catch here is >that it has to be tested with =
the same brand/type of the disk, as while >the layers are usually bas=
ed on acid-soluble metal oxide, they are >frequently coated with a po=
lymer or glass for protection and increased >lifetime; this layer may=
be too resistant to the acid. A suitable mixture >of the chemicals t=
hen has to be used which attacks the protective layer >(hydrogen fluo=
ride for glass, organic solvents for polymers?). I am also >not certa=
in how long the acid eating would take; 30 seconds is quite short >ti=
me. More time can be gained by putting the disk into an enclosure with &=
gt;some minimal guaranteed disassembly time, which buys longer time for =
>eating the plates. The disadvantage here is that we have to dehermetize=
 >the disk; they however typically have protective stickers over some=

holes, >which may serve for convenient entry point for the acid. Ther=
e is also the >problem of finding a suitable valve - most acids and s=
olvents are volatile >and their vapors are highly corrosive, with the=
corresponding impact on >disk reliability. A rupture disc made of gl=
ass or a suitable polymer >(teflon?) that gets pierced or shattered w=
ith a small explosive charge (a >blank round?), or melted through wit=
h a small heating element, or pierced >mechanically, may find an empl=
oyment here. Storing the acid/solvent in an >elastic bag pressurized =
with a spring to make sure the content will flow >out in a desired ti=
me may be an advantage. > > > > >Now somethin=
g less noisy and more practical. > > > >Another pos=
sibility is avoiding hazardous materials entirely and encrypt >the
disk with a 256-bit AES, making bruteforcing highly impractical and >=
converting the problem of destroying an entire disk into destroying just<BR=
>>some 32 bytes. Then store the key in a SRAM that can get electronicall=
y >erased. It would be needed to occassionally swap the bits in the S=
RAM to >prevent their "burn-in" (eg. each second or ten invert all by=
tes of the >key, and remember if the key is stored plain or inverted)=
. Make the device >tamper-sensitive so an attempt to open the dongle =
or enter a wrong >key-unlocking PIN too many times will lead to zeroi=
ng of the key. Realize >the disk encryption either in hardware (eg. w=
ww.opencores.org contains >open-source implementation of AES for an F=
PGA, allowing design of a >pass-through IDE module), or in software (=
eg. using Linux with a suitably >hacked bootloader, or booting from=

ROM with code that asks the key storage >module for the disk key and =
then loads the OS). > >This method also allows a wider security=
margin, as the key may be stored >off-site in a suitable backup (per=
haps concealed, perhaps in an escrow in >a suitable jurisdiction, per=
haps split between several people in a m-of-n >scheme). This also all=
ows repeated testing of the assembly, the OS, and a >key-destruction =
trigger (which may be also linked to a burglar alarm >system, denying=
disk access if a forced entry attempt to the room with the >secured =
machine is detected) under conditions of a simulated attack. > &gt=
;The key has to be truly randomly generated (a hash of couple seconds of<BR=
>>noisy audio?). To generate a 256-bit hex key of a decent strength we c=
an >use eg. this line of code (assumptions: Linux, noisy audio of
suitable >level at /dev/dsp): >for x in 1 2; do dd if=/dev/ds=
p bs=512 count=1 2>/dev/null | md5sum |tr -d '\n -'; done ><BR=
>>(explanation: dd reads one block of 512 bytes from /dev/dsp (the sound=
card >input - has to be selected and set to suitable signal strength,=
so it >gives nonrepeating analog data; the noisier the sound is, the=
better). The >md5sum then turns the not-entirely-random data into a =
hash of 16 bytes >(128 bits) length, increasing the per-bit entropy b=
y so called whitening. >MD5 is a broken hash function, however this d=
oes not really matter in this >application. The md5sum output is then=
stripped from spaces and separators >and end-of-lines. The operation=
is repeated twice, to get 256 bits of key. >You can substitute any o=
ther hash functions or entropy sources, as your >conditions, applicat=
ion,
and level of paranoia requires.) > > > >Here we can=
also build the disk as a network-attached storage, and access >the d=
ata from a remotely booted diskless station. This way no data are >pe=
rmanently stored in plaintext form. The RAM is cheap, so no swap should =
>be needed for common operations. > > >Some common pit=
falls: >* Unencrypted swapfile. Don't use it or place it on the encry=
pted disk. >* Intercepted plaintext data. Encrypt data transfers, or =
do not do them. >* Compromised key storage. Correctly handle physical=
security and erase > trigger device reliability. >* Compromise=
d hardware. Solve by good physical security of the place where > the =
hardware is located. Do not forget uncommon entry points, eg. > throu=
gh walls, floor, or ceiling. >* Electromagnetic emissions of
plaintext data. Use TEMPEST shielding of > the hardware or a shielded=
room. Uncommon unless dealing with top-budget > adversaries. >=
* HUMINT and PSYOPS. Targetting the operators. Tough to solve, a most &g=
t; likely attack vector. >* Murphy. The one underestimated attack vec=
tor that you forgot and that > gets you. > > > &=
gt; >The later mentioned solid-state Flash-based disk has advantages =
(fast >erase) and disadvantages (relatively small space in comparison=
with 750 GB >hard drives currently available, necessity of having el=
ectrical power >available in order to erase the data - the destructiv=
e devices can be >battery-backed to activate, the SRAM memory for cry=
pto key requires power >to operate). Both disadvantages can be worked=
around by having a dedicated >battery-operated erase unit (IDE
commands can be implemented on a >microcontroller) and by waiting for=
new higher capacities (the development >here goes *FAST*). Also, if =
it gets stolen or lost, the data stay in >plaintext. > ><=
BR>>Opinions, comments? > > > > > ><=
BR>>On Wed, 21 Mar 2007 cont..._at_yahoo.co.uk wrote: > > ><=
BR>> > . > > > > Someone asked me...if i know a way=
to destroy > > a harddisk (contents) in under 30 seconds. >=
> > > I suppose...he wants a harddisk in some housing/box, =
> > ofcourse it´s connected to his computer, > > when the =
moment arrives he pushes a button or activates > > some lever...an=
d in under 30 seconds all contents become > > unreadable forever (=
guaranteed) > > > > Anyone know if something like that is=

available ? > > > > If not...could i built something like=
that myself ? > > the client wants to buy a few of such units.<BR=
>> > > > Overwriting/formatting takes to long...and does not=
erase 100%. > > > > Wich other technics would work ? Mag=
nets ? Acid ? E.M.P.? > > how to implement that in a sellable unit=
? > > > > Thanks ! > > > > Radiotechsc=
an > > > > > > > ></BLOCK=
QUOTE></div> <hr>One Care: <a href="http://g.msn.com/8HMB=
ENCA/2734??PS=47575" target="_top"> free Trial Version Today!</a> </htm=
l>

Received on Sat Mar 02 2024 - 00:57:18 CST

This archive was generated by hypermail 2.3.0 : Sat Mar 02 2024 - 01:11:44 CST