A secured, read-only USB drive.
April 6, 2011 10:36 AM Subscribe
Does anybody know of a secured USB drive with read only (or privileged-write) memory and a built in crypto chip? The UniToken DRIVE would be ideal, but is way too expensive (>$70US per unit). I need something that we can buy wholesale for about $20-30 per unit.
We intend to distribute software on this device, and need to positively identify that the software being run is the software we distributed.
This device needs to store data in such a way that it cannot be written to (without proper authorization), and be able to prove (through a cryptographic chain) that particular bits of data being read are coming from the same device as houses the cryptographic chip.
A simple USB authentication token doesn't work in this scenario, because we need to verify that data hasn't been tampered with, not just that a particular token exists on the system. If you're going to offer an alternative solution based on separate authorization/crypto devices and memory devices, please assume that the attacker is capable of rewriting any portion of the operating system to make his attack.
We intend to distribute software on this device, and need to positively identify that the software being run is the software we distributed.
This device needs to store data in such a way that it cannot be written to (without proper authorization), and be able to prove (through a cryptographic chain) that particular bits of data being read are coming from the same device as houses the cryptographic chip.
A simple USB authentication token doesn't work in this scenario, because we need to verify that data hasn't been tampered with, not just that a particular token exists on the system. If you're going to offer an alternative solution based on separate authorization/crypto devices and memory devices, please assume that the attacker is capable of rewriting any portion of the operating system to make his attack.
This post was deleted for the following reason: poster's request -- jessamyn
Response by poster: The customer should generate the SHA-1 checksum of the file on the disc and compare it with the one you provide to them, and then proceed to decrypt it with the key that you provide to them.
That works exactly once.
Let's say that each time they run the software, I want to be assured that it's the same software I shipped.
We're kind of off in DRM-land (but, I promise this isn't DRM), where the supposed attacker is the authorized user.
posted by Netzapper at 10:54 AM on April 6, 2011
That works exactly once.
Let's say that each time they run the software, I want to be assured that it's the same software I shipped.
We're kind of off in DRM-land (but, I promise this isn't DRM), where the supposed attacker is the authorized user.
posted by Netzapper at 10:54 AM on April 6, 2011
This fundamentally cannot be done without a trusted platform module (TPM) and OS support, which AFAIK is not offered on any popular operating system. In other words, to have Windows prove that the user is running software with the right providence, you would also have to be able to prove that the Windows kernel has not been tampered with. Good luck.
Can you have the client run your software remotely on your own servers instead?
posted by qxntpqbbbqxl at 10:57 AM on April 6, 2011
Can you have the client run your software remotely on your own servers instead?
posted by qxntpqbbbqxl at 10:57 AM on April 6, 2011
How about the SanDisk SD worm card? Google has them at $25 individually priced. I imagine you could include a USB SD reader at your $30 price point in bulk.
posted by bfranklin at 10:57 AM on April 6, 2011
posted by bfranklin at 10:57 AM on April 6, 2011
IronKey seems to be the only USB key where the encryption process actually runs on hardware inside the key itself, rather than the local PC, and even they would be vulnerable to someone simply opening up the physical key.
Let's say that each time they run the software, I want to be assured that it's the same software I shipped.
Look at how hard game companies try to prevent people from running hacked versions of their games, and how ineffective they are. MS, Sony, and Nintendo spend millions trying to do just this, and failing.
posted by nomisxid at 11:04 AM on April 6, 2011
Let's say that each time they run the software, I want to be assured that it's the same software I shipped.
Look at how hard game companies try to prevent people from running hacked versions of their games, and how ineffective they are. MS, Sony, and Nintendo spend millions trying to do just this, and failing.
posted by nomisxid at 11:04 AM on April 6, 2011
Response by poster: This fundamentally cannot be done without a trusted platform module (TPM) and OS support, which AFAIK is not offered on any popular operating system.
Well... what if the software we were distributing were the only software running on a computer? This isn't a windows program, this is just some executable code.
Listen, honestly, I do know what I'm doing here (building a cryptographic chain of trust). I've been wrestling with this issue for several days now, and I'm not the sort who exclaims "crypto" and assumes the problem's solved. I'm just not at liberty to disclose what exactly we're doing.
So, let's focus on fulfilling the basic requirements I asked about, please.
posted by Netzapper at 11:05 AM on April 6, 2011
Well... what if the software we were distributing were the only software running on a computer? This isn't a windows program, this is just some executable code.
Listen, honestly, I do know what I'm doing here (building a cryptographic chain of trust). I've been wrestling with this issue for several days now, and I'm not the sort who exclaims "crypto" and assumes the problem's solved. I'm just not at liberty to disclose what exactly we're doing.
So, let's focus on fulfilling the basic requirements I asked about, please.
posted by Netzapper at 11:05 AM on April 6, 2011
what if the software we were distributing were the only software running on a computer?
This would work. Essentially, you'd be distributing your own operating system along with the program. See Nexus for a research OS that is designed to do this.
The good news is that you wouldn't need any fancy USB dongle; establishing a chain of trust that is grounded in hardware is exactly what TPMs are for, and TPMs are standard these days in many business-class computers.
You could also take a look at what companies like Blizzard do to prevent tampering with a client's version of World of Warcraft. Their solutions are not going to be theoretically sound as long as they're running on something like Windows, but they have a huge financial incentive to make a "good enough" deterrent to hacking.
posted by qxntpqbbbqxl at 11:17 AM on April 6, 2011
This would work. Essentially, you'd be distributing your own operating system along with the program. See Nexus for a research OS that is designed to do this.
The good news is that you wouldn't need any fancy USB dongle; establishing a chain of trust that is grounded in hardware is exactly what TPMs are for, and TPMs are standard these days in many business-class computers.
You could also take a look at what companies like Blizzard do to prevent tampering with a client's version of World of Warcraft. Their solutions are not going to be theoretically sound as long as they're running on something like Windows, but they have a huge financial incentive to make a "good enough" deterrent to hacking.
posted by qxntpqbbbqxl at 11:17 AM on April 6, 2011
It's still not clear exactly what attacks you'e trying to prevent.
and be able to prove (through a cryptographic chain) that particular bits of data being read are coming from the same device as houses the cryptographic chip.
Prove to whom? If your application needs to prove to itself that its data hasn't been tampered with, then you're in the exact same place as everyone who's trying to build better copy protection. Any verification checks in the software can be altered.
Well... what if the software we were distributing were the only software running on a computer?
If your hardware supports it, there are Linux TPM drivers. The way this works is that every step in the boot chain, starting with the BIOS, hashes all the code it loads and sends this hash to the TPM. It's possible to store data, such as keys, in the TPM such that they can only be unlocked if the machine is in a "known good" configuration.
posted by teraflop at 11:18 AM on April 6, 2011
and be able to prove (through a cryptographic chain) that particular bits of data being read are coming from the same device as houses the cryptographic chip.
Prove to whom? If your application needs to prove to itself that its data hasn't been tampered with, then you're in the exact same place as everyone who's trying to build better copy protection. Any verification checks in the software can be altered.
Well... what if the software we were distributing were the only software running on a computer?
If your hardware supports it, there are Linux TPM drivers. The way this works is that every step in the boot chain, starting with the BIOS, hashes all the code it loads and sends this hash to the TPM. It's possible to store data, such as keys, in the TPM such that they can only be unlocked if the machine is in a "known good" configuration.
posted by teraflop at 11:18 AM on April 6, 2011
Response by poster: The good news is that you wouldn't need any fancy USB dongle; establishing a chain of trust that is grounded in hardware is exactly what TPMs are for, and TPMs are standard these days in many business-class computers.
Okay, except let's assume the computer itself does *not* have a built-in TPM, and we want to provide it in the USB dongle.
Seriously, check out that UniToken DRIVE I linked above the fold. It is precisely, mathematically what I need. (And, if you want to sign an NDA, I can show you the proof.)
It's just too expensive.
posted by Netzapper at 11:20 AM on April 6, 2011
Okay, except let's assume the computer itself does *not* have a built-in TPM, and we want to provide it in the USB dongle.
Seriously, check out that UniToken DRIVE I linked above the fold. It is precisely, mathematically what I need. (And, if you want to sign an NDA, I can show you the proof.)
It's just too expensive.
posted by Netzapper at 11:20 AM on April 6, 2011
This thread is closed to new comments.
The customer should generate the SHA-1 checksum of the file on the disc and compare it with the one you provide to them, and then proceed to decrypt it with the key that you provide to them.
As long as your keys are not compromised, this should ensure that the software has not been tampered with, and also that the disc is useless without the key if it falls into the wrong hands.
Also, if you're trying to guard against a man-in-the-middle attack, where somebody intercepts the device and substitutes it with a similar one, your encryption problem gets much, much more complicated, especially if they're able to intercept both the media containing the software, and the media/paper containing the key. In that scenario, you're defenseless.
posted by schmod at 10:50 AM on April 6, 2011