Welcome Guest [Log In] [Register]
Welcome to Crypto. We hope you enjoy your visit.


You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free.


Join our community!


If you're already a member please log in to your account to access all of our features:

Username:   Password:
Add Reply
Creating A Per User Encryption
Topic Started: May 14 2007, 03:55 PM (364 Views)
Revelation May 14 2007, 03:55 PM Post #1
Member Avatar
Administrator
[ * * * * * ]
 Recently I had to create some data with a group, but because it is our work we didn't want anyone else to read it. Unfortunately, someone in the group sent it to a friend of his and that friend sent it to all the other people, so everyone ended up having that document.

That made me think of a way to protect your data and still making it readable for a group of people. This is what I made up:

For each computer a special key gets made that depends on the hardware of that computer. If a member of my group wants to get the data, they give me the key and I will give them another key that enables them to read the data. So if someone wants to give a code to a friend, they can't read it.

Of course there are some security issues and other issues with this method. For example, if someone changes their own computer key in the memory, they can still get the data. And, how do you encrypt the data?

Furthermore, if the document gets decrypted and it is displayed on the screen, someone could read it using a window hook. So the data has to be printed on the screen in a special way.

Does anyone have any comments and suggestions on this system? I really want to create this application, just for the fun. It would be great if we could create a failsafe system!
RRRREJMEEEEEPVKLWENFNVJKEEEEEAOLKAFKLXCFZAASDJXZTTTTTTTLSIOWJXMOKLAFJNNKFNXN
RAGRBAQEMHIGDJVDSEOXVIYCELFHWLELJFIENXLRATALSJFSLCYTKLASJDKMHGOVOKAJDNMNUITN
RRRRLJVEEEEECLYVYHNVPFTAEEEEEMWLMEIRNGLARWJAKJDFLWNTIERJMIPQWOTZEOCXKNUBNXCN
RJIRPOWEANFUSNCZVDVZNMSFEKLOEPZLDKDJWSAAAAAAAOERHJCTNCKFRIMVKSOFOMKMANREWNBN
RZUDRGXEEEEENFQIDVLQNCKNEEEEEDGLLLLLLAWIOSNCDARLODMTOEJXMILDFJROTKJSDNLVCZNN
Offline Profile Quote Post Goto Top
 
loki May 15 2007, 11:24 AM Post #2
Advanced Member
[ * * * ]
 What about time based encryption,

IE: Its encrypted on your side, and when you wish to share someone you decrypt your copy and create and new temporary copy based on a time limit, a day or a few hours.

See before you pass the temp copy you create a temp key and re-encrypt the file with that key. Giving the person that temp key, user atuhentication is through the unique computer id, once the user authenticates and open the files a simple message is sent saying the file was open and the countdown begins. If the person still wants the file after the deadline, repeat the process in the background.

I wonder if your application was to create a virtual machine in seperate memory space if that would prevent a hook or not? OR a virtual user like a windows service.
c(x) = 3x3 + x2 + x + 2; Find the inverse
Offline Profile Quote Post Goto Top
 
jdege May 15 2007, 06:15 PM Post #3
Member Avatar
Elite member
[ * * * * * ]
 It seems to me that your fundamental problem is with your users, not your software.

You can encrypt your documents, and provide a machine-locked decryption program, that can only be run on machines to which you've provided machine-specific keys, but that won't keep people from distributing the decrypted documents.

You need a secure viewer, not just a secure decryption utility. So that the documents are viewable only through a machine-locked program. And even that won't keep people from doing print-screens.

So the only thing I see that could work would be something to allow you to determine who distributed the document. Preventing people from doing so isn't something you can fix in software.

  • You create an encrypted document

    • Your program stores each page of the document as a high-resolution JPEG
    • Your program encrypts the document with a random key
    • Your program writes the key to a keyfile
  • User receives encrypted document
  • User installs your secure viewer application - but does not have a license file
  • Running the secure viewer application without a license file brings up a request license file wizard.

    • Viewer application determines a machine-ID for the machine it's running on. (MAC address, CPU/disk serial numbers, etc.)
    • Viewer application emails a license request to you, including the machine-ID.
    • You email to the user a license file containing both the decryption key for the document and information identifying the user, encrypted with the machine-ID.
    • The user copies the license file into the installation directory (or perhaps the viewer application has an option for installing a license file.)
  • The user runs the viewer application to view the document

    • The application decrypts the license file with the machine-ID, to determine the decryption key of the document.
    • The application decrypts the document, and modifies each page, before displaying it - adding to each page the user information from the license file, both as visible text and as a hidden watermark.


If the user prints and distributes the document, the identifying information will be present. If the user cuts-and-pastes, the JPEG will contain the identifying watermark. The user could print the document, cover the obvious identifying information, then photocopy the result, but it might be possible to add an identifying pattern of speckles that might survive through that.

The fundamental problem is that if you can't trust the people you're distributing your document to, you can't trust the people you're distributing your document to. They could, for example, copy the document out by hand, or retype it into a new document that has no continuity with the old.

But it's possible that there are some of your users who might be disuaded from distributing the document, if they knew that they could be identified unless they took extraordinary measures. Particularly if they knew that there were hidden identifiers in the document, but didn't know what they were or how they worked.
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
Offline Profile Quote Post Goto Top
 
Revelation May 15 2007, 07:23 PM Post #4
Member Avatar
Administrator
[ * * * * * ]
 Thank you both for your input :)

It sounds like a plan. I was also thinking of creating a key that only works on a specified computer, because its value has to be added to a hash created out of the system specs.

I also think people will be really demotivated to start a complicated copy procedure, and in my case, they would not want to write it down themselves, since then they have done the work my group did :P

Now I want to implement this in a nice way. Has anyone of you got a nice free visual editor by the way? Creating windows in Dev-C++ from scratch is really frustrating!
RRRREJMEEEEEPVKLWENFNVJKEEEEEAOLKAFKLXCFZAASDJXZTTTTTTTLSIOWJXMOKLAFJNNKFNXN
RAGRBAQEMHIGDJVDSEOXVIYCELFHWLELJFIENXLRATALSJFSLCYTKLASJDKMHGOVOKAJDNMNUITN
RRRRLJVEEEEECLYVYHNVPFTAEEEEEMWLMEIRNGLARWJAKJDFLWNTIERJMIPQWOTZEOCXKNUBNXCN
RJIRPOWEANFUSNCZVDVZNMSFEKLOEPZLDKDJWSAAAAAAAOERHJCTNCKFRIMVKSOFOMKMANREWNBN
RZUDRGXEEEEENFQIDVLQNCKNEEEEEDGLLLLLLAWIOSNCDARLODMTOEJXMILDFJROTKJSDNLVCZNN
Offline Profile Quote Post Goto Top
 
PulsarSL Jul 1 2007, 09:26 AM Post #5
Super member
[ * * * * ]
 Windows Media Player has some way of preventing print-screen jobs. Not sure exactly how it works, but I imagine it involves DirectX somehow.
Offline Profile Quote Post Goto Top
 
1 user reading this topic (1 Guest and 0 Anonymous)
« Previous Topic · General · Next Topic »
Add Reply