>From my point of view is the problem that there is a password/key that exists >for the encrypted data. The possibility that the key is known/can be stolen >is a realistic risk. As long the data is within the owners control this risk can be handled, but not after the disk leaved the company.
Med Vänlig Hälsning Thomas Berg ________________________________________________________________ Thomas Berg Specialist z/OS/IT Delivery SWEDBANK AB (Publ) > -----Ursprungligt meddelande----- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > För Ron Hawkins > Skickat: den 15 december 2012 11:40 > Till: IBM-MAIN@LISTSERV.UA.EDU > Ämne: Re: dsf to write over entire volume > > 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, that's 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
