YubiKeyIdeas/DRM
From Yubico
Contents |
DRM with YubiKey - by Ilkka Pirttimaa
This is an idea how DRM could be implemted using Yubikeys. You could create any number of keys that can be used to open documents, music, etc.
Problem Scenario
There is a company called Corporate A (CORP_A) that has a project with Vendor B (VEND_B). There is lot of Word, Powerpoint and Excel docs in CORP_A that has to be send to VEND_B. Also VEND_B have to send documents back.
Documents contains confidential information. They need easy way to make sure documents can be opened only by the project members either in CORP_A or VEND_B. Using PGP etc. is not userfriendly enough for all team members.
Solution
Solution is a concept where documents sent using email or USB-sticks are encrypted with one Project-key (for example AES128). There is need for easy fatclient for encrypting and decrypting. Idea of ths conecpt is that key is stored into centrilized server (for example in COMP_A's DMZ that also VEND_B can access) and accessible only with registered Yubikeys. Fatclient that is used get's key when needed only if Yubikey used is authorized for that projectkey.
More technical description
Yubico has centralized yubikey authentication server which is used only for validating key.
If solution needs any data stored for each key it must use it's own local database for store it (for example user name, email address etc.) For pincode and password it is obvious it should be in your own database but in this case there is no shared DB that could be used.
It would be nice option to be able to save some content into the authorization server – In this case it would be projects AES-key.
That could be done as a separate authentication server that acts as ”man-in-a-middle” feeding requests to Yubico authentication server and giving just the same results back to the querier (in this case CORP_A is hosting that server). It could also run own validating server if that was needed.
The trick is that this service will provide some extra features to feed extra data in or out. It is possible to call yubikey_client_request with extra tagname. If there is data blob stored for that tagname that data is returned with yubikey response. We need also a way to store that blob (somethink like yubikey_client_request_settag(...)). HTTPS is used for these queries cause there is secret data involved.
This service can be used to provide DRM (digital rights management): If you had for example ten team members, you would get ten Yubikeys and set for each of them tag called "<myProjectname>.securekey" :
yubikey_client_request_settag(c, "dteffujehknhfjbrjnlnldnhcujvddbikngjrtgh","<myProjectname>.securekey",mysecurekey)
That would save securekey for that Yubikey only if OTP-validation was ok. That data blob has a secret key that you use to scramble content. After initialization of those 10 keys you give them to persons that you want to have access to any document you later send (encrypted with "mysecurekey") them through unsecure email. When user on a client side opens that document, fatclient asks yubikey authorization and would get secret key only if yubikey is authenticated ok (metadata is returned only if authorization was ok). Document is decrypted with that key and opened.
In a first implementation Mac/Linux/Windows fatclient would be used to do authenticating OTP and getting projects secure key.
I believe that it could be possible to create for example PDF-add-on with same functionality: In PDF file itself there would be data block that identifies where it's authentication server is and what tag name should be asked to get AES-key. This would be ideal, cause PDF would be always stored encrypted and decrypted only into memory, if you had one of the authorized keys when opening it.
