Protecting & viewing multiple file types / document formats with DRM

Are native applications an advantage for DRM protected documents?

There are many DRM confidential content control systems available that appear, at least from the literature of their suppliers, to be able to apply DRM content control to many different types of files.

Here it seems we need to give some careful thought as to exactly what claims are being made (for Europeans consider examining the UK Brexit claims before and after the poll?).  Rather like the politicians, it seems to depends on exactly what you mean by applying control(s).  To be explicit we are talking here about access to content and nothing else.  Now if we take the argument that we are just protecting content, then it follows that there are the following distinct ways of protecting multiple file types when adding DRM controls to data content:

1. Produce several custom viewing applications, one for each file type, so that the feature/functionality/processing is reproduced and the recipient experience is maintained as if they were using the original file type application (if you want to process an .xlsx file reproduce the whole functionality of Microsoft Excel);
2. Convert different document types into a meta-form (flash has been very popular, as has PDF) but prevent any further altering of the original because you are not reproducing all the functionality of the original application;
3. Stick a plug-in (or as some say add-in) in the application and be very careful it can’t be hacked or messed up following an application update.  And good luck.  Plug-ins are notorious for causing security issues and breaking, especially when applications are updated by the original product manufacturer.

Method 1 is very elegant but it is also very expensive.  Designing the functionality of Excel is a non-trivial undertaking, as Microsoft would confirm (even when they hid a complete copy of flight simulator in the code).

If you try enveloping the file and releasing it back to the normal application the real problem is created by the presence of a lot of code capable of carrying out actions (such as Save, Copy, Print) that you are trying to control.  And all the attacker wants to do is get hold of those commands and the security has gone.  So if your Viewer is trying to stop access to functions that are there, the attacker has something obvious to aim at.

Method 2 is the most reliable.  There are several reasons why.  You can get Systems Development Kits (SDKs) for rendering popular file formats to screen, and they allow a Viewer developer to constrain the functionality that is exposed, and how it is exposed.  So exposing undesirable functionality can be more readily avoided.  And the other great problem, the habit of applications to make disk copies locally for speed of processing, can be avoided because the Viewer provider, and not the subject application, is in control of processing and is able to avoid known security weaknesses, but only because they have taken control.

Method 3 is potentially the worst option.  You may be compromising the security of the application and face a stream of annoyed users as and when a product update stops it from working and users viewing your DRM protected documents.  Plug-ins or add-ins may be attacked directly because many products allow for developer type operation, a mode that allows an attacker to ‘see’ the code he is trying to defeat.  And all the original functionality (save, print, etc.) is accessible in the underlying code which the plugin tries to prevent the user from accessing.

But when it comes to it, if none of the methods offer editing capability then what advantages do you get from using the native application?

Well the answer is none – you are actually at a disadvantage.  The native applications have all the functionality available to defeat the controls you might want to apply.  And more widely used file formats such as the ubiquitous PDF for example can be viewed on Linux, Mac and mobile operating systems, which cannot be said for Microsoft Office files using ODF (older formats can be processed just fine).  So using a native application will actually limit who can use your protected documents.

So if you think that you are looking at systems that claim to protect multiple file types, be sure to check out what functionality is available with the protected files.  Likely you will find that what is really meant is several different file formats can be converted to a specific secured format for presentation to the recipient, and not for editing at all – defeating the whole purpose of supporting multiple file types (users expect to have the functionality of the native application available).

Do not confuse DRM controls with network access controls, commonly used by network management and operating system tools.  These are often limited to basic access controls  Read, Write, Append, Delete, Execute.  These may well function adequately for internal document collaboration but do not cut it when documents have to go outside of the domain of control of the originator.  For that you need custom viewing applications and a format that gives a reliable rendering of content to screen.