Locking Documents for IPR control
Although one of the primary requirements in PDF DRM (Digital Rights Management) is to identify the authorized user of a document, and make sure that only that person can use protected documents, it is relatively difficult to identify people, and although the IT industry has been working on improving the well out of date ID/Password combination, it is still in common use for flexibility of operation when better tools are available.
The difficulty with user authentication technology is that there is no consensus as to how to operate global schemes for personal identification/authentication, and no infrastructure either. The best authentication schemes are currently those of the credit and debit card providers, and you might say that what they really authenticate is an account number with some behaviour history. They also authenticate the device being used and the location of the device.
Authenticating machines to authenticate people
But we can learn a great deal from some of the general principles of the card provider’s approaches.
It is reasonably possible to identify ‘uniquely’ an electronic device (such as a PC or a tablet or a USB token) because the manufacturers burn a unique identity into their devices so they can identify them with some certainty, and to prevent device forgery.
So it becomes possible to triangulate a claimed identity (commonly an email address, but any arbitrary identity will do), a physical device, and an authority to open a protected document. And that is critical to being able to operate PDF DRM services. The ‘claimed identity’ must be associated with the device, and the authority is locked to the device. Usually a registration process is needed so that an external ‘umpire’ holds the references linking an identity to a device. This is the scheme that Locklizard PDF DRM authentication uses with its installed Secure PDF Viewer applications.
So although it seems a bit of a circular argument, you can authorize a specific individual to use one or more protected documents, and to do it reasonably reliably.
When we are talking about tablet devices it is likely that they have just one user, but desktop machines may have more than one (not in my case since I have more than one personal desktop, and need to license them all in most scenarios, which no doubt pleases some manufacturers), and on the other hand mobile phones tend to be highly personal.
To conclude: it is possible to link an identity to a unique device, and to process licensing information on that basis. This effectively resolves the technical difficulties of user identification by setting up a system where the user identifies themselves by a series of steps that an attacker would find impractical to reproduce.
Using tokens instead of machines for identification
This also works with unique devices such as flash drives or USB tokens. Previously we were concerned with linking an identity to a physical device, and then linking licensing information dynamically with wherever the license is being installed. When licensing tokens, the licensing is usually carried out when the token is personalised rather than waiting to see where the license gets registered from and recording the hardware identity. This is also to ensure a reliable and well known product is distributed, as poor reliability will result in expensive replacement and administration costs.
This is not a significant difference for document control purposes because in this case the authorisation (license) applies to the token and not to the computer it is being connected to. So it fits very neatly into the Locklizard Secure PDF USB approach to user and device authentication.
When you license a PC or a tablet then you are expecting to license the user of that device, and that they cannot give the documents to someone else who is not licensed. When a token has been authorized, then anyone who has control of the token is able to use the licensed contents – BUT – the content cannot be copied onto a different token and used from there because the device identity will be different. Also the original token user will be denied all access if the token is given away. From an operational perspective, if the information is valuable, the authorised recipient is unlikely to want to give it away because the loss of access is critical. Also, during the personalization phase of the token it may well be possible to introduce the identity of the intended recipient of the token, and thus later be able to detect if indeed the authorised user is using the token.
Adding IP location control(s)
So far we have considered hardware addresses as identity controls. The MAC address of a PC is a physical location control – the address of a given physical device. The same is true of the identity of a token. It is a physical thing that cannot be altered without (effectively) destroying the system itself. So they are powerful controls. But that may not take us far enough. We know what the device is, but not where it actually is. And laptops, tablets, and mobile phones can travel.
For document DRM systems to function they need to communicate with licensing servers, and that means having an Internet connection, and therefore using an IP address allocated by a broadband supplier. IP addresses are usually registered in blocks by country, so every networked machine has an external IP address that identifies a user and probably a location.
We may need to be more precise about where a device or token actually is, as part of the controls. There are many examples of where internal documents need to remain internal regardless of where the individual given access to the protected document(s) happens to be physically located.
Perhaps the simplest example is the ‘library’ use of documents. For licensing purposes, libraries commonly come to agreements with Copyright Collecting Societies about the fees they pay annually to allow their users access to documents. But they work on the basis of being able to provide access to all the ‘copies’ they have available (and electronically speaking that could be a large theoretical number). But that does not mean that copies may be borrowed (taken off the premises so denying access to other potential users). Of course if you want a lending scheme, then the token system will work perfectly well because borrowing the token equates to borrowing the document (book).
That type of control requires that you limit access to a specific network address or range of addresses. These would have to correspond to actual IP addresses to make any sense. So ‘localhost’ in Windows would not make any sense since almost any network would have that as a connection. And internal IP address ranges such as those of the form 10.*.*.* would not make any sense because they are commonly used as internal addresses and lots of networks will have them.
But a good old hell for leather IP address like 126.96.36.199 (or if you want the DN veterans.gov) will work perfectly and will require that the user be on that network address (or DN) before they can actually use protected documents.
That has only considered the use of an internal domain. It may be that you want to tighten it down to the specific IP that they connect with. Now this might prove awkward, especially if you don’t happen to know in advance what that address is, but applications such as Safeguard Enterprise PDF DRM provide the facility to be able to enforce the IP address that they use to register as being the address they have to use in order to open the protected document(s). This mirrors the liking of the user to the device we talked about earlier.
Locking documents to specific country locations
You may have to take into account country addresses. This may be useful if you do not want people to be able to access protected documents when they are in particular countries (or regions). Examples could be that you do not want documents to be opened if your user(s) are, for instance, in Mexico, or Iran or Iraq.
This may be because the content is proscribed in a particular country, or that a competitor owns the IPR of some information in that country (for instance it happens in tobacco where Benson and Hedges is either owned by Philip Morris International, British American Tobacco, or Japan Tobacco, depending on the region).
It is equally possible that you wish to only allow documents to be opened whilst the user is in a specific country. This could simply be that controlled documents must not go outside the country, or there may be a stipulation about where documents may be published for copyright reasons or it may be that you have different licensing policies applicable to different countries.
Changing security settings after distribution
Finally, you have to consider that people move about – whether that is travelling, changing jobs, moving offices etc. You therefore need a system that is flexible enough to enable you to update PDF security settings on-the-fly, so you can change IP and location data to accomodate those situations.
For PDF DRM, in an ideal world, we would identify the actual person wishing to open a protected document. But it turns out that it is difficult to do that. At a more practical level we can identify hardware and link a hardware identity to an individual in a similar way to credit card processors. This is less than perfect – I can give my son my credit card and the PIN and who is any the wiser – but it works fairly well.
Also like credit card processing there are many reasons to want to know where the user is, either on an internal network or by global positioning. In their case to make sure you don’t change countries/locations improbably quickly. In PDF DRM it is to prevent use in unauthorized locations or to require the user to be in specific territorial limits.
These features complement more regular document DRM controls and provide overarching management of access to information that model existing and well-tried methods and technologies for authentication and use. Safeguard Enterprise PDF DRM has available the features needed to achieve these extensions of IPR control.