Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Privacy Hardware

The Always-Encrypted Firewire Hard Drive 230

ducman points to the announcement of an encrypted hard drive running on the MacNN website. The drive features a DES 64-bit/ 40bit key strength and "is intended for use by banks, insurance providers, government agencies, and those individuals with sensitive digital intellectual property. It supports the IEEE 1394a connectivity standard, in addition to USB 1.1 and 2.0. It offers data transfer rates over FireWire 400 of 100, 200, or 400 Mbps. The SuperGuard is expected to be available February 7." Sounds great -- but the USB key stuck in the back looks like a likely point of failure.
This discussion has been archived. No new comments can be posted.

The Always-Encrypted Firewire Hard Drive

Comments Filter:
  • worthless (Score:5, Insightful)

    by Anonymous Coward on Saturday February 01, 2003 @02:26PM (#5205108)
    the key length is too short.
    • by Anonymous Coward
      the key length is too short?

      is that a masculinity problem?
    • Re:worthless (Score:2, Insightful)

      by Haroldo ( 136587 )
      This can be useful for hard disk disposal. A previous slashdot story informed about old disks being bought on ebay to be scanned for deleted data. With this encription approach, at least data will be disposed deleted and encripted. For sure, making the work much more difficult.
    • the key length is too short.

      40 bits too short? Bah!

      My external harddrive has a 1 bit key. It's a rocker switch on the back with a 0 and a 1. If you don't enter the right key the entire drive shuts down.

      -
    • the key length is too short.

      64 bits should be enough for anybody.
  • This sounds useful (Score:1, Interesting)

    by Anonymous Coward
    I recently switched from Mac OS 8 to OS X. The one thing I miss is PGPdisk (the most recent freely available version doesn't run on OS X). I've been using Disk Copy encrypted images which use AES 128-bit encryption but I don't know quite how that compares to PGPdisk. So all in all I could definitely use a better encrypted drive solution.

    One of these puppies would be a neat alternative. Probably a bit costly though.
    • by Anonymous Coward
      OS/X can be made to support it ... AFAIK Darwin does.

      - Make a big file image, format it, mount it via loopback, encrypt everything that goes on it.
    • with 128-bit encryption and such.

      Is there an encrypted filesystem I could use in Linux?
    • Actually this is downright cheap, the site lists the enclosure at $139 US which is almost exactly what all the other 1394/USB2 enclsures cost. From my perspective you get the encryption for at most a couple of dollars, pretty cheap investment to me =) As to the security, it's not terribly large, and it's single pass which pretty much no one does for DES anymore but it's better than nothing. It also does it at line speed with no CPU overhead which is cool. Now if they could offer a model that would do 128bit AES at line speed I would definitly purchase one (I may anyways as I find myself in need of a firewire enclosure)
  • 3rd post! (Score:5, Insightful)

    by Anonymous Coward on Saturday February 01, 2003 @02:29PM (#5205120)
    Encrypted loopback devices on linux and bsd (and MacOS) are easier and cheaper.

    And more secure IMHO.
    • by marmoset ( 3738 ) on Saturday February 01, 2003 @02:50PM (#5205251) Homepage Journal

      Encrypted disk images are really easy to use on OS X. They're encrypted using AES-128 (much more secure than the above hardware solution) and the performance is really quite good (fast enough to playback Quicktime movies from, even on a G3.) The Apple KBase entry on how to use them is here [tinyurl.com].

      • I use them all the time. I have a 40GB 2.5" firewire drive that I shuttle back and forth from the office. It has 3 encrypted images on it that I use for offsite backups of our most important data.

        Performance isn't bad at all. I don't even notice it in my application since my bottleneck is the 100T connection to the server rather than the 400Mb Firewire bus or the encryption speed, but even with local copies, a G4 should do a fine job of keeping up with the Firewire bus.

        The FW 800 bus will be a little different matter. Maybe the dual 1.42 G4 can do it, but I doubt my lowly PB could.
        • >Performance isn't bad at all. I don't even notice it in my >application since my bottleneck is the 100T connection
          >to the server rather than the 400Mb Firewire bus or the
          >encryption speed, but even with local copies, a G4
          >should do a fine job of keeping up with the Firewire bus.

          >The FW 800 bus will be a little different matter. Maybe
          >the dual 1.42 G4 can do it, but I doubt my lowly PB
          >could.

          While it's fine to get excited about fast busses, it's important to remember that they're that fast because they're designed to support a bunch of drives, not because each drive is actually capable of pushing that much data. If you're luicky, the drive inside the enclosure is a 7200 rpm ata drive, which isn't capable of filling the ata100 bus on it's own, let alone a firewire 800 bus.
    • Loopback devices are a silly hack. It was nice to add a quick feature. But what is really needed is a smooth, seamless, truly integrated solution which works at the virtual device layer, above individual device drivers, but below filesystems and direct device opening. The reasons for this include the fact that you can't partition loopback devices (that's another issue) and the number of loopback devices being limited. This needs to be made totally transparent except for the fact of enabling it and setting the key (probably an integrated ioctl() and/or /proc operation). Every device (and partitions count) need to be able to have their own separate key and encryption state.

  • Does my mp3 collection count?
    • Sure it does. Anything you want "secured" is a good candidate.
      I enclosed secured in quotation marks because nothing is truely secure.

      On a more "On Topic' note, I bet the Co-operators insurance company wishes they were using a similasr technology last week as this article [therecord.com]
      exemplifies.
      Guelph-based Co-operators Life has warned more than 180,000 customers about possible identity theft after the disappearance of a computer hard drive containing sensitive personal information....


      "Vital information such as name, date of birth, social insurance number and mother's maiden name" can be used to access financial accounts, transfer bank balances and apply for loans and credit cards, Co-operators CEO Kathy Bardswick said in the letter this week.
  • Wow super secure (Score:5, Insightful)

    by Anonymous Coward on Saturday February 01, 2003 @02:30PM (#5205130)
    And it only took 6.4 seconds to crack into once the harddrive was hooked up to a standard PC.

    Anyone in here actually read Applied Cryptography? This was 1995 when it was published, and especially for bank use, you'd NEVER use anything less than a 128 bit key.

    Also, did they say DES or 3DES? Hasn't DES been cracked?

    • Re:Wow super secure (Score:5, Informative)

      by Bishop ( 4500 ) on Saturday February 01, 2003 @02:50PM (#5205254)
      DES has not been cracked. It has been bruted forced in a short ammount of time. There is a difference.

      That said DES and possibly even 3DES should no longer be used.

      • DES weaknesses (Score:5, Interesting)

        by billstewart ( 78916 ) on Saturday February 01, 2003 @03:53PM (#5205634) Journal
        3DES is just fine - as you say, DES hasn't been cracked, it's just been brute-forced, and 3DES increases the brute-force work by 2**56, which means it'd take about 2**56 days to brute-force instead of about 1 day. The only reasons not to use 3DES are that it's 3 times slower than DES (no big deal here), or that you trust AES well enough to use it instead (about 10 times faster than 3DES), or that you don't have enough room in some existing protocol to store a 112-bit or 168-bit key, in which case you should probably fix your protocol instead.

        "40-bit DES", on the other hand, is either a well-designed crock or poorly-designed crock, which is pretty trivial to crack. The only reason to use such any 40-bit key is to comply with anti-Communist US export regulations that got dropped a few years ago, largely due to the EFF's DES-cracker machine and the internet distributed DES crack effort, both of which emphasized the weakness of 16-bit DES.

        On a technical note, cracking well-designed 40-bit DES subsets is not 2**16 times faster than cracking 56-bit DES, or John Gilmore could do it in 3 minutes in his basement. DES has two main phases, a key-scheduling phase and an S-box phase, and the DES cracking efforts took advantage of some interesting work by Peter Trei on key scheduling, which found a search order that makes each key-schedule a simple modification of the previous one, instead if its normal relatively slow calculation. So a 40-bit DES crack might take 5-10 times as long per key as a 56-bit DES crack, unless the 40-bit subset was designed to avoid that. On the other hand, the EFF and Internet DES cracks were in 1998, and computers have gotten about 8-10 times faster since then...

        • 3DES is just fine

          No it is not. though the 3DES key is three times as long as the DES key, the 3DES block is still exactly the same size as the DES block. A 64 bit block is simply too short, you will get vulnurable to the so called birthday attack.

          With a reasonable security margin you can encrypt no more than 512KB with the same key. If you encrypt 35GB with the same key you can be almost sure, that your data is no longer safe.

          I'm also wondering if this product even uses a safe mode of operation. It is easy to use a per sector CBC mode with block number as IV (like cryptoloop for Linux), but that is just not secure. A secure solution has to offer some of your disk space and access speed, I think a 10% cost would be likely.
          • Longer blocks are good, but birthday attacks only matter when someone can construct a problem where they let the attacker do something useful; that's highly unlikely for most disk encryption algorithms, which are used to haul around large sectors of disk space, e.g. 512-8192 bytes. 35GB may be enough that you'd have two 64-bit blocks of disk that have identical cyphertext and different plaintext, but it's not useful to anybody.

            As fast as safe operation modes goes, the nice thing about 40/56/64-bit encryption is that you scarcely have to worry about whether something else is the Weakest Link instead :-(.

      • Still, a fact of the matter is that this company is touting "military grade" security, but in some ways the milititary _is_ as insecure as DES. :)

        At least there is a review on that firewire product that correctly points out that the encryption needs work.
        • The "military grade" security phrase is always one of those "key points" which always seems to mean that the product being advertised is smoke and mirrors...
        • Read this paper [counterpane.com] to see why 40-bit keys are so bad.

          However, to point to where the "military grade" security claim is coming from is the fact that in many military situations information is only needed to remain secure for minutes or a few hours. Unfortunately for FW Depot, that generally applies to wireless communications, not data stored on hard drives.

          Maybe they are hoping that people will use it to courier sensitive data...but then they could just hire Johnny Mnemonic.

          Yeah, bad product trying to meet ITAR regulations so they can export.
    • better then nothing [canada.com]
    • Re:Wow super secure (Score:3, Informative)

      by tweakt ( 325224 )
      Hasn't DES been cracked?

      DES hasn't been cracked per-se but the 40bit keyspace can be scanned very efficiently now with distributed computing and specialized hardware.

    • As other posters have noted, DES hcan easily be brute-forced because its key length is too short. It is also academically "broken," meaning that there is an attack faster than brute force.

      A linear attack breaks DES in 2^40-something encryptions and 2^40-something known plaintexts (compare 1 known plaintext and 2^53 work for brute force). This means order of 10 terabytes of data, though, so we don't have to worry about it. Nobody will be using DES by the time anyone will be lazy enough to encrypt 10TB of data with a weak code.
    • Why is everyone concentrating on the key length? The method in which they are using DES here is far more relevant.

      If you take an entire hard drive and encrypt it sector by sector under a DES key, you've got a problem. There's plenty of plaintext and matching ciphertext available by virtue of known disk structures, and the possibility of constructing a birthday attack is high. Worse, there are parallel attack mechanisms that allow you to break such a scheme in 2^40 tries instead of 2^56. That's under a day for someone with serious money.

      But most HDD encryption schemes don't work like that. At work you use a key variant for every sector -- xor the sector number onto the key, so that you effectively have a different key per sector. This helps to reduce the effectiveness of some attacks (e.g. the parallal attack), but suffers a critical problem: break the key for one sector, and you've got the drive.

      A far more secure scheme involves key derivatives: encrypt the sector number with the key to find a derived key, then encrypt the sector with that key. Breaking a single sector still doesn't break the master key. This mostly limits you to a known plaintext attach, and raises the complexity to 2^57 (you have to break two keys, the second being the one you want).

      Other schemes include the use of multiple keys over a disk, so that breaking a single key only compromises and area (say 1/4) of the disk.

      As for the security of DES; it hasn't been cracked. There are some ways to reduce its strength in particular circumstances (see above), but not generally.

      Like it or not the banking world still uses DES (yes, 56 bit keys) and will continue to do so for some time to come. Check out the ANSI financial services standards (which govern interbank electronic standards, like ATM networks). Is this a problem? Not really. Intelligent use of protocols ensures that cracking the key is a waste of time because at best you can recover a single PIN ... which is more easily brute forced at 10^5 than a DES key at 2^56.

  • DES?!!? (Score:5, Interesting)

    by patrik ( 55312 ) <pbutler@kille[ ]x.org ['rtu' in gap]> on Saturday February 01, 2003 @02:34PM (#5205150) Homepage

    DES has been replaced by Rijndael (AES)in the govt. Or at least that's what's supposed to happen, DeS is no longer secure enough. I would bet that with the huge ammounts of data stored on a disk differential techniques would make it a snap to get the key. What's worse is an easy to crack crypto system that you believe in is worse than no crypto system at all since you're likely to store data on it that you might not store otherwise.

    Patrik

    • Re:DES?!!? (Score:3, Informative)

      AES really hasn't been deployed that much in practice, however 3DES has been standard for quite some time. Cracking DES by differential techniques is non-trivial. The biggest problem is that it can be cracked by dedicated hardware costing only a few million dollars, or by a group of computers in a distributed system. And if you're using 40 bit DES then that's just completely worthless.

      -a
  • by aardvarkjoe ( 156801 ) on Saturday February 01, 2003 @02:36PM (#5205164)
    The ACs in this thread are correct. 40 bit encryption isn't going to keep anyone but a casual snooper out of your data.
  • by BrianUofR ( 143023 ) on Saturday February 01, 2003 @02:39PM (#5205181)
    From the article:

    *Device driver free, operating system independent

    *Microsoft Windows98 SE, Windows ME, Windows 2000, Windows XP and Mac OS compatible

    First off, how can it be OS independent and have a list of compatible OS's? If it's a hardware-based solution, then how can some OS's not work with it?
    • First off, how can it be OS independent and have a list of compatible OS's? If it's a hardware-based solution, then how can some OS's not work with it?

      Maybe because those OSes don't support USB.
    • Starting with Win 2000 there is some sort of portable drive standard. I know the OS 10 has built in support as well.

      I have a portable drive that when plugged into XP,2000, and OSX, it recognizes and mounts.

      I have a driver disk for 98.

      The company I bought it from told me that Linux didn't have built in support for it yet.

      Puto
      • Dont always believe what the manufacturer is saying. They most probably meant that THEY dont support it in linux....

        for ieee1394a its called sbp2...

        and linux DOES have support for it (the standard)... the problem is drives that DONT follow the standard....
        http://www.linux1394.org/sbp2.html

        for usb it called the mass-storage class... and same issue applies. Linux supports the STANDARD... which some manufacturers may not fully follow....

        http://www2.one-eyed-alien.net/~mdharm/linux-usb /
    • First off, how can it be OS independent and have a list of compatible OS's?

      It's just a marketing phrase. It doesn't necessarily mean anything. It's like Sally Struthers saying "earn your degree in almost anything" and then she lists stuff like "dog grooming". The list serves as a set of ideas for people unwilling to believe the word "anything" and who only click when they hear the one word important to them.

      That's not a contradiction, it's just annoying ad copy. Keep in mind the kind of people writing ads. Watch TV for a few minutes and see that while broadcasters are upset over ad-skipping Tivos we might have a strong case to sue them for cruel and unusual punishment.

      More annoying ad copy is the advertising which says "up to 10, or more!". How can it be more?? They just said it's up to 10!

      Truly annoying (and common) are the ads that say "Sugar...because cookies would be bland without it.", or "Diamonds...because we've got everyone duped." Well, actually, I never asked why!
  • Encrypted? (Score:3, Insightful)

    by SirCrashALot ( 614498 ) <jasonNO@SPAMcompnski.com> on Saturday February 01, 2003 @02:40PM (#5205194)
    # Real-time 64-bit/ 40-bit DES (Data Encryption Standard)
    I hope this is a joke.... DES is no longer secure, hence the creation of AES. Why build a device that uses DES when there are machines that can crack it in a few days that cost only $25,000. The more money you have to spend, the faster you can crack it. DES Cracking machine [eff.org]
    An encrypted drive is a cool idea, but i would much rather use CFS (crypted file system) on a regular drive than this. DES offers no security to the people who want your data.
    • Who cares? This is a great proof-of-concept. Once it has been implemented using DES, it is pretty trivial to switch to another block cipher like AES.
  • by t0rnt0pieces ( 594277 ) on Saturday February 01, 2003 @02:41PM (#5205199)
    If you want to prevent someone from getting your data, just buy a Western Digital drive. No one will be able to recover it!
  • by Kiwi ( 5214 ) on Saturday February 01, 2003 @02:43PM (#5205205) Homepage Journal
    Why do I get the feeling this product will end up in the doghouse section of Bruce's next Crypto Gram newslatter [counterpane.com]?

    The people who designed this hard disk are confused about how DES works. First of all, DES has a 56-bit, not a 64-bit key. Second of all, the days of being forced to use 40-bit encryption are, thankfully, over.

    If one is going to all of the effort to encrypt a hard disk, why will they encrypt it using only Single DES? It is possible to build a single-DES cracker for under $10,000 US; the 56-bit key which single DES has to offer is just not long enough.

    They would have been much better off encrypting this unit with AES [plus.com], which uses Rijndael [rijndael.com] to encrypt files. Rijndael has a key size between 128 and 256 bits long, which can not be brute forced with current technology. Rijndael is also more efficient than DES when implemented in software.

    Also, security is only as strong as its weakest link. If the hard disk is always readable when the key card is attached, then great care must be taken to detatch and hide the key card. Far better security can be obtained by a system which asks for a passphrase. Ideally, have a system which needs both the key card and the passphrase.

    While I think this is a good idea, I think one is better off with the kernel patches which allow one to encrypt [sourceforge.net] filesystems [kernel.org] in Linux.

    (For windows and Mac users, sorry, I use neither so can not help you)

    - Sam

    • In that vein, does anyone know of a product like this that *is* secure (or atleast has the hope of being secure?)? The only thing I've seen are extremely crappy software modules that end up dumping your data right quick :)
    • Win2000 and XP have filesytem encryption support on a per-folder or entire disk basis (I believe). Anyone familiar with the strength of the encryption and speed?
      • Win2k and above use DESX, an extension of DES that allows for an effective 120bit keylength when compared to plain DES. This allows reasonable security without the overhead of say 3DES. Encryption is accomplished though use of a public key in combination with a salt value that is stored in the files description.
        • You're right, it does use 40-bit or 120-bit (MS likes to count the 8 parity bits in addition) DESX.

          I hadn't heard of any salt being used. Salts are completely useless if you're using a seperate strongly (pseudo-)random key for each file. If you're not very very careful, the salting may also very slightly reduce your key space.

          If you're using an encrypted fielsystem, make sure your password is stored only using the NT hash. By default, both the LM hash and the NT hash of your password are stored in the registry. In the absolute best case, the work foactor is somewhere aroudn 2 ** 56 to break a 14-character strong password. If you password doesn't require you to hold down the alt key while using the nueric keypad, you're most likely looking at a work factor of about 2 ** 37 to crack your password. (Your password is borken into 7-character halves and converted into upper case, then something like an unsalted UNIX crypt algorithm is applied seperately to each half.) Once they have your password, they can decrypt your SK and get all of your files. Game over man, game over.

          Microsoft should be applauded for making a default install crypto-filesysm capable. However, per-file encryption falls to some attacks and information leakage that volume-level encryption doesn't suffer from. Swap space and temp files are still a big problem without third-party add-ons.

          It's also important to note that RSA Labs designed DESX explicitly as a stop-gap measure until the Advanced Encryption Standard (AES) was decided upon.

          MS could also have done the world a great service by including 40-yaer old password salting technology instead of using unsalted password hashes.

        • Win2k and above use DESX, an extension of DES that allows for an effective 120bit keylength when compared to plain DES. This allows reasonable security without the overhead of say 3DES.

          DESX is broken, and not just academically. See Applied Cryptography for details (it's by Bruce, btw). Any instance of DESX that is as fast as DES is no more secure. It is only slightly better in strength vs performance than 3DES. It was a nice idea, but it didn't work out.
    • OS X users can use Disk Copy

      http://www.apple.com/macosx/technologies/securit y. html

    • One thing that strikes me is that the usb decription key reader is mounted in the BACK of the unit. It would make more sense to mount the key reader on the front of the unit where the key could be plugged in while attached to a teather clipped to the person using the computer.

      Placing the key reader in the back only encourages people to leave the key in the unit which provides even less security, (read none), than the DES encryption provides.

    • Technically, DES does have a 64-bit key; it's just that eight of the key bits are used for parity checking and contribute nothing to the security of the algorithm, leaving the key with 56 bits of entropy. Many software implementations do away with the parity bits altogether and just use a raw 56-bit key, but the original spec called for 64-bit keys.

      All this is, of course, IIRC.
  • Wow. Not only does it have a silvery case, and and the blue stripe, but it comes with a pretty purple keychain! Now if only I could figure out why it came with the drive, and what it is for...
  • Why would they just release a hard drive based on Firewire 400 when the 800 just came out? Wouldn't it be better to embrace the new tech?

    On the other hand, they probably don't want to force people to buy Apple's high end stuff to use their drive: they aren't Apple, after all.
    • Re:Why 400? (Score:1, Insightful)

      by Anonymous Coward
      Why would they just release a hard drive based on Firewire 400 when the 800 just came out?

      Besides the fact that a single hard disk isn't going to saturate a Firewire 400 bus, you've answered your own question: it just came out. So it'd be useless unless you owned one of the newest 17" PowerBooks, which won't ship for "6-8 weeks".

      I'm all for embracing new technologies, but why release a hard disk enclosure that supports a standard nobody's even using yet? (Maybe if they also sold Firewire-800 PCI cards...)
  • Part of the security of this device is the fact that you shouldn't let it get into unwanted hands. Yes, I agree the encryption standard is weak as hell. This is a first generation technology, so give it a break. I think the weak encrypion was compromise since, as many have pointed out, the hard drive is rather slow and it has to encrypt things...

    I'll bet there are other companies working on a similar technology, I won't purchase one until I get variable key length and some decent speed specs.

    -Code
    • I think the weak encrypion was compromise since, as many have pointed out, the hard drive is rather slow and it has to encrypt things...

      All the AES candidates (Rjindael, Twofish, Serpent, MARS, etc) were engineered to be as fast as possible in software and in hardware. Encryption chips are already available for Rjindael and IIRC Twofish as well; even if not, they could make an ASIC for it on such a big project. Speed is not an issue here.
  • I really wish I could get a scsi version of this. Internal or external, external would be a lot easier, but some kind of internal addon board would be really good. I don't want to start an ide/scsi debate, but if I had data that was so important it needs that kind of security I would spend more than $200 on the drive.
  • Not so crap (Score:4, Interesting)

    by maroberts ( 15852 ) on Saturday February 01, 2003 @02:54PM (#5205274) Homepage Journal
    Those who've criticised it for it's key length have missed a perhaps an important point, which its that it encrypts without consuming the processor power of the host machine and supports full bus transfer rates whilst encrypting. If your system processor load is a bit hairy, you perhaps don't want to add to it by trying to encrypt on the CPU.

    Still, the same device with AES, 3DES or similar would be much better....maybe next time!!
    • The encryption isn't strong enough to keep out a skilled professional or a medium-sized group of annoyed amateurs. Therefore it offers no benefit over simply using its authentication token device as a password substitute, which is good enough to keep out unskilled amateurs. Meanwhile, the fact that they're even bothering to use 40-bit encryption, and that they're claiming it's military-grade security, and that it's good enough for several sets of users who might have actual security needs that this clearly isn't good enough for is a strong indication that these guys are at best technically clueless, or else blatantly dishonest. So you could buy one of these as a n IDE-to-Firewire/USB2 adapter, but I'd be worried about the thing losing my data as well as not keeping it secure when the CIA spooks sneak through my windows at night to steal the evidence I've collected about the Roswell aliens. Also, it's not subpoena-proof, because the key is (at least apparently) kept in the little key-frob, rather than being something you enter yourself, so any court that can force you to turn over the drive can force you to turn over the key-frob (as opposed to forcing you to tell them a password, which you can argue about.)
  • It looks like as long as you've got the little dongle-thingy your drive will work; without it you're toast. So aside from any concern about the (only) 40-bit encryption, it seems like you'd have to make sure you hid the key (and not forget where you hid it). And if the key or its socket were to, ummmm... break or something (it's an external enclosure, so it could fall and the wires break), well you wouldn't have any data at all. And if the key got stolen, well then the thief only has to stick the thing into the drive and voila, there's your data.

    I know a lot of corporate IT types will think this is exciting, especially as new data security laws keep hitting the books. Full time encryption seems pretty secure. And the price seems fair, especially since it seems to take any EIDE drive and secure it, and (quoted from the article), "capable of maneuvering 66MByte/ sec throughput without taking any system resources." Just don't lose that darn key! And maybe they'll develop an internal version that would be more secure from bumps, knocks, and falls.

    Now, I've gotta get one of them new-fangled firewire (or USB 2.0) ports. And a hook to hang the little dongle from.
  • False advertising (Score:5, Informative)

    by Bishop ( 4500 ) on Saturday February 01, 2003 @02:57PM (#5205287)
    From FireWire Depot page [http]:

    "...offers the military grade protection for your classified data."

    Calling DES "military grade protection" is pretty close to a blatant lie.
    • Sure it's military grade. Pitcairn Island military though, not U.S.
    • Re:False advertising (Score:4, Informative)

      by Detritus ( 11846 ) on Saturday February 01, 2003 @03:14PM (#5205402) Homepage
      The last time I checked, DES was only authorized for the protection of SBU (Sensitive But Unclassified) data. This would include things like personnel and medical records. Classified information requires protection by NSA approved algorithms and hardware. As far as I know, Skipjack is the only published algorithm that has been approved for the protection of classified information, and that is only for the lower levels of classification.
    • Re:False advertising (Score:2, Interesting)

      by Anonymous Coward
      Hey- it doesn't say "US Military Grade". I'm sure it holds up quite well to the Haitian or Cuban military standards of encryption.
    • DES is obsolete and would not be used for sensitive information by the US Military.

      But they didn't say who's military ;-)

    • Re:False advertising (Score:3, Informative)

      by AIXadmin ( 10544 )
      Someone forgot to tell them that AES has replaced DES as the SBU standard.
  • Drive Failure (Score:5, Insightful)

    by po8 ( 187055 ) on Saturday February 01, 2003 @02:59PM (#5205296)

    ...the USB key stuck in the back looks like a likely point of failure.

    Conceivably. Anyone who is running one of these drives without backups somewhere is even more insane than the folks running un-encrypted drives without backups. The backups themselves can easily be encrypted, so there's no need for major security risk. If your key dongles stop working or your drive fries, you'd better have some way of getting the bits back from outside, 'cause they're not coming from the platter.

    OTOH, what is "64-bit/ 40-bit DES" supposed to be? Presumably this means the drive supports "40-bit watered-down DES keys" and "64-bit normal DES blocks". So I guess I'm wrong: this drive is designed to be break-inable in an emergency. Great. I'll wait until they offer 3DES or AES-128 options, thanks.

    In the meantime, check out the BSD Cryptographic disk driver cgd [stanford.edu]: SW on-disk encryption at the block level.

    • or in 5.0, gbde [freebsd.org] (GEOM Based Disk Encryption)

    • I've recently been brainstorming about a P2P encrypted backup system. It would create automatic, encrypted backups using something like FreeNet or OceanStore to distribute redundant, encrypted backup fragments on other people's computers (and vice versa). I know P2P and security are almost oxymorons, but I think it could work securely.

      Are there projects like this already? Or applications like it built on top of existing "overlay networks" like FreeNet?
      • Freenet retrieval is too unreliable unless the documents are very popular. Hope that your encrypted data is not a hugely popular download.

        P2P can be done securely, depending on your threat model. DOS attacks against P2P systems is still a largely unsolved problem. However you could easily make a system that is for all practical purposes immune to data disclosure. (GPG encrypt your data to yourself befre distributing it, for instance.) I have a nice little perl script that makes a nightly tarball of my CVS repository and GPG-encrypts it, then puts the encrypted tarballup on the web under a filename that contains 64-bits of the md5sum of the unencrrypted tarball. (taken pre-compression). On the backup storage machine, there's a perl script to chck if the md5sum fragment has changed, and if so, use wget to backup the tar ball. (This most defintely isn't P2P, but it deonstrates a simple example of a backup system that lets thee entire world see the backup, yet is for all practical purposes immune to data disclosure.)

        If you had a distributed cooperative file system, you could use my perl scripts do do your backups, and the only notable attack (aside from compromise of your machine) would be a DOS/deletion attack against the cooperative filesystem. Of course, you need to chack signatures on the tarballs when you decrypt them.

        I was actually talking with one of the Freene developers about his efforts provide distributed encrypted anonymous storage. Unfortunately, the DOS/deletion problem is still unslved, so he was forced to go with storage only on his machines, which means it's not P2P. Most P2P stems are also so transient that you'd need a very high level of replication.

        Of course, there's a simple modification to my perl script system that you could make... have it scan random IP addresses for open SMB shares... that would be "non-cooperative distributed filesystems" :-P

  • I recently wrote a silly little pam module and edited some files in gdm so I can login at my Red Hat linux terminal just by walking up and sticking in my Trek Thumbdrive.

    One of the problems I've been wrestling with is that if anyone copies the file from the thumbdrive that it looks for, they can access my system as easily as I can. This hard drive would seem to suffer the same problem.

    So, you say, protect the usb key just as a regular door key - you don't let people copy those. When I get my car serviced I even make a point to only hand them the car key alone, and not my apartment keys, etc.

    But the small usb drives are so damn convenient as a replacement for floppies, and in fact I bought mine so I could throw files on it and take them to people's computers. But if I've got a login file on mine, the second I insert it into someone's computer I've theoretically lost security, because they could have a background process that copied off the file.

    Now of course I'm not in the habit of trading files with miscreants and criminals, but you get the idea. If I'm building a process that's ostensibly for security it might as well be good.

    But I haven't been able to find a way to reconcile the login issue with using the usb key elsewhere. As far as I can see, a perfect copy of my login file is as good as the original.
    • I assume the USB key is like a smartcard where the key is programmed at the factory and can not be accessed without the proper matching key which is probably flashed to the drive controller and not easily accessible.
    • Use a key generator and generate new keys whenever a key is used. This way, if someone gets a copy they would have to use the key before you used yours, or their key would no longer be valid.

      This reduces, but does not eliminate the risk.

    • Does the key have a serial number? If so, you may launch a script that authenticates off that as well.
      Of course, usb keys are for storage. There is hardware [ibutton.com] designed for what you want to do.
  • Look, I don't know why people make this more complicated than it needs to be.

    Scramdisk (free) and Drivecrypt (cheap) both do on-the-fly en/decryption on regular hard drives. 1024 (and I think 2048) bit keys are available, with your choice of algorithm, and it's incredibly easy to use. For the truly paranoid, you can even use a fully encrypted disk on the fly for your entire OS.

    I don't at all understand what the benefit of special hardware in the drive would be.
    • Well, it appears in this particular case there is less than an advantage to going the hardware route, but theoretically, hardware could could provide a much faster and secure solution.

      For instance, encrypting and decrypting the data via software would cause cpu and memory overhead on the host machine. The encryption software would also need to be installed on all machines that you want to use it on, and this is looking to be a portable drive. Also, using an external encrypter, it's less likely that a keygrabber or trojan can grab your password.
  • Perhaps IBM could put them to use [machit.com] next time an insurance company comes to them for colocation.

    IBM has lost a hard drive containing the records of 180,000 clients of an insurance company. Details include "names, addresses, beneficiaries, social insurance numbers, pension values, pre-authorized checking information and mothers' maiden names", according to wire reports. Anything else? Oh yes, their bank account details.
  • A few days ago, I read in MacCentral [macworld.com] that Weibetech [wiebetech.com] had developed a AES based system to encrypt hard drives.
  • Yeah, the encryption is weak, blah, blah, but that's beside the point. Isn't the data only as secure as the application that can access it? I guess these things are only used behind a firewall then, and they are just encrypted to protect against physical theft. They can't provide any security if the server is net facing can they? I mean, if Apache can access the data then just crack Apache above the level of drive access.

    • This is a very important point. People don't usually haul around big hard drives, especially in bigger cases. Getting such hard drives stolen is rarely a point of failure (yeah, Canadian blah IBM blah blah). Much more of a risk is someone hacking it while it sits there connected to a computer with the dongle in.

      Maybe something like this would be useful on a laptop, but encrypted loopback devices probably solve the problem better because the dongle could get lost, stolen etc. The only thing you have to worry about there is speed.

      The biggest problem seems to be how to get the password into such a device. The next disk format / drive type spec should have optional encryption (of the whole drive) built into the spec to allow the password to be entered in a user-friendly manner. This would allow, say, encryption on CDs that is transparent to userland processes (not for copy protection, but for data protection).
  • WiebeTech is going to do the exact same thing, only with AES instead. http://www.kuro5hin.org/story/2003/1/6/234015/4753
  • From the features page:

    # Microsoft Windows98 SE, Windows ME, Windows 2000, Windows XP and Mac OS compatible

    Is that a feature? Or a limitation?


    All I need for my "secure" alternative:

    128 bytes of storage for some random data, to which I then append a password to and use as the encryption key in my crypto-loopback [kernel.org] software implementation.

    What do those "artistic" MAC users have that they need to keep secret anyway? This? [ubergeek.tv] Also mirrored (aka stolen) here [damnit.org]
  • by jkbull ( 453632 ) on Saturday February 01, 2003 @10:20PM (#5208130)
    If you look at the actual specs [fwdepot.com], and the fact that the enclosure provides "Real-time... Encryption/ Decryption" all this enclosure does is to encrypt the data going out, and decrypt traffic coming in. The data on the actual hard drive does not seem to be encrypted. This enclosure is not going to stop anyone who bothers to actually open the case, remove the hard drive and put in their own enclosure/install it in their own computers. Nobody in their right mind should use this case, unless potential data thieves are going to nicely agree to keep the hard drive in its pretty enclosure, or the manufacturer adds a lock to the case.

Business is a good game -- lots of competition and minimum of rules. You keep score with money. -- Nolan Bushnell, founder of Atari

Working...