Radoslaw,
I'm not sure about the other vendors, but for HDS data at rest encryption
and secure erase have not been available for 15 years as you say. They have
been available for half a decade and two product generations.
I think all the vendors are supporting full AES 256 encryption. I'm not a
cypher expert but a bit of interesting reading on wiki suggest that brute
force is not going to make the cut in cracking this, and other techniques
require leaks or incomplete implementation of AES 256. The following gave me
a surprise as to the scale of computing and time required for a brute force
attack:
" AES permits the use of 256-bit keys. Breaking a symmetric 256-bit
key by brute force requires 2128 times more computational power than a
128-bit key. A device that could check a billion billion (1E18) AES keys per
second (if such a device could ever be made - as of 2012, supercomputers
have computing capacities of 20 Peta-FLOPS, see Titan. So 50 supercomputers
would be required to process (1E18) operations per second) would in theory
require about 3E51 years to exhaust the 256-bit key space. " from
http://en.wikipedia.org/wiki/Brute-force_attack.
On average brute force will probably hit pay dirt with half the
permutations, but even if it gets lucky with a hit at just 0.001% of the
keys, thats still looks like a lot of zeroes and a lot of centuries to me,
even if replacing the supercomputers with cloud, grid or a truckload of
graphics cards doubled the operations per second.
I think there are two things that have changed from 15 years ago. As you
reference, one is that secure erasure became vogue due to the urban myth
that the contents of a disk drive could be completely reconstructed by
reading the bits on a track that were randomly laid down outside the mode
write path of a head. Vendors had to respond to this so that customers
weren't keeping all their disk drives when they sold or traded in a
controller. Sounder heads have prevailed and this idea is being filed away
with some of Ian Fleming's best books, but having a process to erase the
contents of a disk drive with one pass (or more) without a host attached
remains a good idea. Most recently reviewed security standards only require
a single write pass for the track to be considered securely erased.
The second thing that has changed is that encryption has superseded secure
erasure as an acceptable method to secure data on a HDD or SSD once the
drive leaves the data center. There has been some change in physics, such
that relatively cheap ASICs can be installed in the disk array back ends to
process the AES256 cipher without any impact to performance, and I'd suggest
that this followed adoption AES256 relatively quickly. Using encryption from
initial install prevents clear text from being left in remapped sectors and
tracks.
I guess the moot point is whether you accept that brute force cracking of
AES256 is typically measured in thousands of aeons, and must start with the
resources and planning to run for that time if they don't get lucky in the
first five minutes.
Ron
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: Thursday, December 13, 2012 10:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] dsf to write over entire volume
>
> W dniu 2012-12-13 18:22, Ron Hawkins pisze:
> > Radosalw, (Radoslaw, pronounced like Radoslav ;-) )
>
> >> Encryption is a matter of time and cost. The question is WHEN I will
> > decrypt
> >> the data, not IF. And WHEN depends on my budget (the more money the
> >> more zombies works for me) and piece of good luck (I can guess the
> >> key 5 min. after start or as last possible value).
> >>
> > [Ron Hawkins] I'm not sure I follow the point. Encryption occurs when
> > the data is destaged to the array group, and decrypted when you read
> > it from the disk. There's no overhead to this . If you mean switching
> > encryption on for existing array groups then yes there will be some
> planning involved.
>
> I think you missed the point. Encryption does not prevent data from being
> read, it does DELAY the moment when "hacker" will read the data.
> If the dealy is measuer in centuries that's OK, but nowadays the are
methods
> to accelerate decryption (brute force) attacks i.e. using grid, cloud or
just
> bunch of PC's, possibly using GPU ("VGA" card processors), possibly using
> hacked machines without onwers awareness.
>
>
>
>
>
>
> BTW: This is significant: few years ago nobody suggested (and offered)
full
> disk encryption inside dasd arrays, nobody was selling security erasure
> features for those arrays, nobody was selling data erasure programs
> operating at OS (MVS) level. However degaussers for tape carts were around
> us even then.
>
> What was changed? Physics? No. Maybe with exception of SSD as new
> media.
> The issues addressed by the above means had existed for years. 15 years
ago
> it was also possible to play with bad sectors of disk coming from dasd
array,
> or preferrably with whole healthy tracks on such disk.
>
> What was changed?
> IMHO two things: minor change in available tools for potential hackers and
> major change in our minds. Changes driven by "horror stories"
> presented in IT newspapers. Majority of them does not describe real
attacks
> but possibilities of such attacks. Considerations how many times should
the
> track be overwritten with random data to erase residual vestiges of data
at
> sides of the track...
>
> That remains me thesis from some movie - probably Bowling for Columbine
> - the number of violence acts decreased sligthly over the years, but the
> percentage of report about those acts in the news increased 10 times.
> There are specialized TV teams "hunting" for accidents, fussilades, bank
> robberies, madmen with guns, etc.
>
> Maybe it's the same in IT - the vulnerabilities remain unchanged for
years,
> but we talk about them much more. ;-)
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
> przeznaczone wycznie do uytku subowego adresata. Odbiorc moe
> by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie
> jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym
> do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie,
> kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze
> jest prawnie zabronione i moe by karalne. Jeeli otrzymae t
> wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc
> wysyajc odpowied oraz trwale usun t wiadomo wczajc w to
> wszelkie jej kopie wydrukowane lub zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties.
If
> you are not the intended addressee of this e-mail or the employee
> authorised to forward it to the addressee, be advised that any
dissemination,
> copying, distribution or any other similar activity is legally prohibited
and may
> be punishable. If you received this e-mail by mistake please advise the
> sender immediately by using the reply facility in your e-mail software and
> delete permanently this e-mail including any copies of it either printed
or
> saved to hard drive.
>
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
fax
> +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego
> Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-
> 021-50-88.
> Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w
> caoci wpacony) wynosi 168.410.984 zotych.
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
