Re: [TSCM-L] {1489} Re: NetSec

From: Its from Onion <areda..._at_msn.com>
Date: Thu, 26 Apr 2007 23:02:03 -0500

>From - Sat Mar 02 00:57:18 2024
Received: by 10.36.18.3 with SMTP id 3mr23866nzr.1174532177029;
        Wed, 21 Mar 2007 19:56:17 -0700 (PDT)
Received: by l75g2000hse.googlegroups.com with HTTP;
        Thu, 22 Mar 2007 02:56:15 +0000 (UTC)
X-IP: 213.10.26.148
From: cont..._at_yahoo.co.uk
To: "TSCM-L Professionals List" <TSCM-..._at_googlegroups.com>
Subject: Re: {1406} Harddisk destroy in les then 30 sec ?
Date: Wed, 21 Mar 2007 19:56:15 -0700
Message-ID: <1174532175.520633.293540_at_l75g2000hse.googlegroups.com>
In-Reply-To: <0703212251240.30508_at_somehost.domainz.com>
References: <1174512089.374460.264800_at_l75g2000hse.googlegroups.com>
   <0703212251240.30508_at_somehost.domainz.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1),gzip(gfe),gzip(gfe)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks !

I=B4d say a combination of high-quality Encryption and SSD-with-fast-
erase option,
would be fine enough (and practically do-able)...
I would insert some small battery (Lithium,1000mAh)
incase of a (voluntary or unvoluntary) mains-outage.
No idea if they have included such battery in current (fast-erasable)
ssd models.

A combination with a (secure) handheld remote (keyhanger)...to
remotely activate
fast-erase would be an interesting and very sellable item.

So you erase it first...if no time or possibilty for that...it would
still be encrypted.


contranl




On 22 mrt, 03:16, Thomas Shaddack <t..._at_shaddack.mauriceward.com>
wrote:
> 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 platters with dust and gravely impairing
> reliability.
>
> First some flashy bangy testosterony ideas.
>
> If I remember correctly, a standard procedure for disk destroying in the
> field when a unit is about to be captured by the enemy is shooting throug=
h
> the disks with tactically important information from a handgun.
>
> A way to quite thoroughly destroy the disk plates and render them
> unreadable against any sane budget level could be therefore multiple
> perforations inflicted by eg. a point-blank shotgun blast.
>
> I hereby propose an arrangement of several (4 to 8?) shotgun shells,
> electrically triggered (independently, for higher reliability), located i=
n
> a circle over the disk plates in steel pipes of a suitable length
> (calculate or test for the best spread pattern) acting as short barrels.
> Once triggered, a storm of metal pieces goes through the plates, shreddin=
g
> the magnetic layer and deforming the plates.
>
> The enclosure has to be specified 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 contractors. This is also why I would caution
> against using mechanical firing system with springs.
>
> A variant of the construction may use a shaped charge that cuts the disk
> plates to pieces in under a microsecond. Again, we do not have to open th=
e
> disk itself (as the charge will cut through the housing), therefore we do
> not impair its reliability nor warranty. Interlocks are again strongly
> advised for. A suitable explosive with required long-term stability and
> guaranteed reliability is however unlikely to be found on open market.
>
> 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 based on acid-soluble metal oxide, they are
> frequently coated with a polymer or glass for protection and increased
> lifetime; this layer may be too resistant to the acid. A suitable mixture
> of the chemicals then has to be used which attacks the protective layer
> (hydrogen fluoride for glass, organic solvents for polymers?). I am also
> not certain how long the acid eating would take; 30 seconds is quite shor=
t
> time. More time can be gained by putting the disk into an enclosure with
> 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. There is also th=
e
> problem of finding a suitable valve - most acids and solvents are volatil=
e
> and their vapors are highly corrosive, with the corresponding impact on
> disk reliability. A rupture disc made of glass or a suitable polymer
> (teflon?) that gets pierced or shattered with a small explosive charge (a
> blank round?), or melted through with a small heating element, or pierced
> mechanically, may find an employment here. Storing the acid/solvent in an
> elastic bag pressurized with a spring to make sure the content will flow
> out in a desired time may be an advantage.
>
> Now something less noisy and more practical.
>
> Another possibility 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
> some 32 bytes. Then store the key in a SRAM that can get electronically
> erased. It would be needed to occassionally swap the bits in the SRAM to
> prevent their "burn-in" (eg. each second or ten invert all bytes of the
> key, and remember if the key is stored plain or inverted). Make the devic=
e
> tamper-sensitive so an attempt to open the dongle or enter a wrong
> key-unlocking PIN too many times will lead to zeroing of the key. Realize
> the disk encryption either in hardware (eg.www.opencores.orgcontains
> open-source implementation of AES for an FPGA, 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 storag=
e
> 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 (perhaps concealed, perhaps in an escrow in
> a suitable jurisdiction, perhaps split between several people in a m-of-n
> scheme). This also allows 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 th=
e
> secured machine is detected) under conditions of a simulated attack.
>
> The key has to be truly randomly generated (a hash of couple seconds of
> noisy audio?). To generate a 256-bit hex key of a decent strength we can
> use eg. this line of code (assumptions: Linux, noisy audio of suitable
> level at /dev/dsp):
> for x in 1 2; do dd if=3D/dev/dsp bs=3D512 count=3D1 2>/dev/null | md5sum=
 |tr -d '\n -'; done
>
> (explanation: dd reads one block of 512 bytes from /dev/dsp (the soundcar=
d
> input - has to be selected and set to suitable signal strength, so it
> gives nonrepeating analog data; the noisier the sound is, the better). Th=
e
> md5sum then turns the not-entirely-random data into a hash of 16 bytes
> (128 bits) length, increasing the per-bit entropy by so called whitening.
> MD5 is a broken hash function, however this does not really matter in thi=
s
> application. The md5sum output is then stripped from spaces and separator=
s
> and end-of-lines. The operation is repeated twice, to get 256 bits of key=
.
> You can substitute any other hash functions or entropy sources, as your
> conditions, application, and level of paranoia requires.)
>
> Here we can also build the disk as a network-attached storage, and access
> the data from a remotely booted diskless station. This way no data are
> permanently stored in plaintext form. The RAM is cheap, so no swap should
> be needed for common operations.
>
> Some common pitfalls:
> * Unencrypted swapfile. Don't use it or place it on the encrypted disk.
> * Intercepted plaintext data. Encrypt data transfers, or do not do them.
> * Compromised key storage. Correctly handle physical security and erase
> trigger device reliability.
> * Compromised hardware. Solve by good physical security of the place wher=
e
> the hardware is located. Do not forget uncommon entry points, eg.
> through walls, floor, or ceiling.
> * Electromagnetic emissions of plaintext data. Use TEMPEST shielding of
> the hardware or a shielded room. Uncommon unless dealing with top-budge=
t
> adversaries.
> * HUMINT and PSYOPS. Targetting the operators. Tough to solve, a most
> likely attack vector.
> * Murphy. The one underestimated attack vector that you forgot and that
> gets you.
>
> The later mentioned solid-state Flash-based disk has advantages (fast
> erase) and disadvantages (relatively small space in comparison with 750 G=
B
> hard drives currently available, necessity of having electrical power
> available in order to erase the data - the destructive devices can be
> battery-backed to activate, the SRAM memory for crypto key requires power
> to operate). Both disadvantages can be worked around by having a dedicate=
d
> battery-operated erase unit (IDE commands can be implemented on a
> microcontroller) and by waiting for new higher capacities (the developmen=
t
> here goes *FAST*). Also, if it gets stolen or lost, the data stay in
> plaintext.
>
> Opinions, comments?
>
> On Wed, 21 Mar 2007 co..._at_yahoo.co.uk wrote:
>
>
>
>
>
> > .
>
> > 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=B4s connected to his computer,
> > when the moment arrives he pushes a button or activates
> > some lever...and 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.
>
> > Overwriting/formatting takes to long...and does not erase 100%.
>
> > Wich other technics would work ? Magnets ? Acid ? E.M.P.?
> > how to implement that in a sellable unit ?
>
> > Thanks !
>
> > Radiotechscan- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

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