Distributing a file so the recipient can't read it
I have a program that is shipped with a data file which I don't want the end-user reading directly. While it's on the user's hard drive, it's always encrypted (even while my program is using it).
However, I can't include the data file with the installer because those are very easy to extract. I've tried encryption features but they don't seem to work quite right.
So I'm trying to find a way to distribute the file so that the user can't read it while it's being distributed. I thought of various ways to download the file via PHP over HTTP in an encrypted form but it's difficult to do so without sending the encryption key over anyway. Not to mention, I'm not very experienced in HTTP matters.
I've come up with some ideas for working around that but either they don't work or they're very complicated. I'd rather come up with a less complicated solution.
This doesn't have to be too secure but it should stand up against a HTTP sniffer. What would be the best way to accomplish this?
It's fundamentally impossible to do this purely in software. If your program running on a user's machine can read it, then another program running on the user's machine can read it; and the user can control that other program, and extract the contents of the file.
You can make it hard; people generally call this feature DRM, and some DRM schemes wind up being tough to break. They become much stronger, and more difficult to break, if you use specialized hardware, which handles the decryption and doesn't allow any non-secured components access the data. But in the end, there's always a way around it; a dedicated user can always hook up a logic analyzer to the appropriate bus and read the data off of it.
If you really wanted to go crazy, you could build in tamper-proof hardware; essentially hardware that has self-destruct features built in, so if the user tries to open the computer up, it destroys the data. This is a rather user-hostile behavior, but in some circumstances is necessary (cards carrying cryptographic keys that you don't want an enemy to be able to obtain).
However, all of this is quite difficult, and expensive, and makes life more difficult for your users. And if there is one, tiny hole somewhere, that one person can crack, then they can just extract the data and post it somewhere; it doesn't matter that it's too hard for most people to bypass, as long as one person can, the game is up.
And of course, all of these hardware based mechanisms require your users to have specialized hardware that supports them; if you're doing a purely software based solution, then the game is up already. The user can just point a debugger at your program's memory and read the contents of the file out when you read it.
So you should probably re-evaluate whether you need such a feature. Is this data really that sensitive? If so, could you keep it under your control, and require the software to talk over the internet to your server that provides a gateway to the functionality provided by it?
If you give a bit more information about your use-case, we might be able to offer better solutions to your particular problem. For instance, if you just want to protect if from casual users, you could encrypt it, and obfuscate the key and code that decrypts it. This won't provide much protection, but it can prevent someone from seeing the contents by glancing at it. If it's for licensing, you might consider using a security dongle or licensing server, that your software checks back with. But no approach will be bulletproof; in the end, if you are trying to do something with this data on your end-user's machine, they will be able to extract the data from your process.
链接地址: http://www.djcxy.com/p/11598.html上一篇: 用于hadoop mapreduce作业的最佳单元测试工具/方法
下一篇: 分发文件以便收件人无法阅读