Kingston Adds 4 GB & 8 GB Capacities to DataTraveler 2000 Encrypted USB Flash Drives with Keypad

Kingston DataTraveler 2000 is a USB 3.0 flash drive that stores files with hardware based AES-256 encryption, and to make sure nobody can access those, it’s also protected with a pin code thanks to a keypad on the flash drive itself. That’s news to me, but the devices have been selling since early 2016 with 16 to 64GB capacities, and you’ll find them on Amazon for $127 and up.

Click to Enlarge

However, since such high security USB flash drives are mostly used for confidential information by enterprises and governments (it’s FIPS-197 compliant), some company’s customers may have complained that 16 to 64GB storage is a bit too much for confidential data, with recent top secret documents leaks or IP thefts, so Kingston has just announced smaller 4GB and 8GB versions of the drives.

Those drives are OS agnostic with encryption occurring inside the drive, and seen buy your computer or other hardware as a normal USB drive after your enter the pin number. For extra security, the company explains “its auto-lock feature is activated when the drive is removed from the host device, and the encryption key and password are deleted after 10 invalid login attempts to thwart brute force intrusions”.

I could not see the new 4GB and 8GB DataTraveler 2000 stick for sale anywhere yet. You’ll find a few more details in the product page.

Via PC Watch (Japan) & Eddy Lab

Share this:

Support CNX Software! Donate via cryptocurrencies or become a Patron on Patreon

10 Replies to “Kingston Adds 4 GB & 8 GB Capacities to DataTraveler 2000 Encrypted USB Flash Drives with Keypad”

  1. I really love the idea, but find them far too expensive. For having found sensitive network captures on one of my USB sticks in the past, I can obviously value this idea, if it really requires zero software to use it.

    Apparently other brands exist (I never saw this in the past) and are slightly cheaper, but not that much. I suspect we’re facing a niche market.

  2. @willy
    When I have to use USB thumb drives (happens not that often fortunately) it’s a simple diskutil call to create an encrypted sparse bundle with the passphrase added to keychain. Encryption/decryption is transparent, one image (sparse bundle) per project/client, problem solved. Only yourself, the persons you share the passphrase with and the NSA can access your data from then on… I fail to develop trust in companies that receive National Security Letters on a regular basis. Applies to Intel (AES-NI), Apple (DiskManagement framework), Kingston (the gimmick above) and all the other US companies 😉

  3. @tkaiser
    Hehe, I’ve never heard about this “diskutil”, though I’ve used loop-aes a lot in the past for my customers FS 🙂

    Anyway, in fact when I have to use a USB stick, it’s because I need to transport data between multiple machines, and sometimes pass it to someone else using a different OS. So that’s why I find the device-based crypto stuff interesting, eventhough it’s hard to trust it of course. But my main concern is not what happens if I’m kidnapped by the NSA who wants the sensitive data my USB stick contains, but what documents/captures become if I lose it in the train, so in general such concerns are properly addressed by these no-so-much trustable security devices, until a backdoor is published and it’s time to switch to a new one.

  4. why not just put aes-encrypted file there, why is the keypad necessary and make the device expensive? a storage is better treated a pure storage

  5. @xxiao
    your method is good (and IMHO better) for many use cases, but not all.
    With encrypted files, you introduce an encryption software dependency and some users can’t afford it.

    As a *not so theorical* example, imagine a company which has an IT security policy that forces its employees to use encryption on all the mobile storage devices they use at work.
    If a marketing guy has to give a talk out of his office and uses this kind of usb key to store his presentation, then he doesn’t have to care about OS/software compatibility on the computer provided by the host. Once decrypted, it just works as a regular usb key.

  6. @nobe
    I do always the following at customers when asked to use ‘foreign’ storage (be it a thumb drive or a server share) and being warned I should not look around since ‘confidental stuff’ here and there: I immediately open up a Terminal window and start a

    It happened only once that the guy who gave me the thumb drive asked what I’m doing, usually I had to inform them what happened afterwards (my machine having fuil access to foreign storage being able to copy everything — the destination can be different than /dev/null and a daemon can be active on my machine immediately starting in the background once a new drive/share is connected).

    So if such an encrypted USB device with a keypad is used to enforce stupid ‘security’ policies it would also need a huge red led showing device activity (to let the marketing guy being informed when it’s already too late). And IMO it’s pretty obvious why such ‘policies’ don’t work and per client/project crypto containers are the way better solution.

  7. @ddiss
    I looked through your slides (thanks!) and start to wonder whether there’s a business case for such a fully open ARM device that can be used as an USB thumb drive without additional cabling:

    – USB OTG directly wired to a male type A connector
    – eMMC
    – FEL button implemented and easily accessible (important!)
    – Thumb drive form factor with enclosure
    – Few useful GPIOs exposed and accessible (eg. male jumper wires?)
    – cheap but powerful SoC (so most probably Allwinner H5 since A53 and supporting ARMv8 crypto extensions)
    – maybe a cap added to allow the device surviving short periods of not being powered (switching the device between two hosts)

    It would be great if the device could detect running off an USB2 (500mA) or USB3 port (900mA available) but I lack any ideas how to implement this (maybe using an USB3-A jack with some circuitry to detect ‘noise’ on the additional pins and then toggle a ‘900 mA GPIO’ bootloader/kernel can rely on to choose appropriate settings to prevent underpowering situations?)

    If there’s an interest maybe we can convince FriendlyELEC exploring such a device (with their loads of compatible accessories it would be easy for them to allow optional stuff to be added, eg. a small OLED display, an RFID reader, whatever)

Leave a Reply

Your email address will not be published. Required fields are marked *