TT Lab
Get started
Learn Learning paths Courses

Enterprise Authentication Integration

Why a DRM-Protected Document Will Not Open on the Server

Continue in TT Lab

Summary

A DRM-protected document has only an ordinary-looking extension and is actually ciphertext, so it never opens on a server without the agent — this is not a bug but a design.

The first scene in the field

An inquiry comes in from a production approval system.

"The attachment will not open. It says 'The file format or file extension is not valid.'"

A developer logs into the server and checks the file. The size is normal and the extension is .xlsx. They download it locally and open it, and it opens. But the user says it does not open. There is the opposite situation too. A batch on the server tries to parse that Excel file and keeps failing.

What you need to know at this point: that file is encrypted. It is because of DRM.

What DRM does

Corporate document security in Korea (DRM, Digital Rights Management) works roughly like this.

  1. A DRM agent is installed on the PC.
  2. When a user saves a document, the agent encrypts it automatically. The extension stays the same. It looks like an ordinary .xlsx.
  3. When a user opens the document, the agent asks the policy server for permission, and if allowed, decrypts it in memory and hands it to the Office program.
  4. Permissions are applied per person, department, period, and action (view/edit/print/screen capture).

In other words, the file itself circulates in encrypted form, and the agent does the decryption. There are several points where this structure causes incidents.

Why it does not open on a server

The server has no DRM agent. So from the server's point of view, that file is an unknown binary with only an xlsx extension.

There is a one-line diagnosis.

file 첨부파일.xlsx
head -c 4 첨부파일.xlsx | xxd

A normal .xlsx is a ZIP, so it starts with 50 4B 03 04 (PK..). A DRM-encrypted file starts with a vendor-specific header or random bytes. With these two lines, you can tell "the file is corrupted" from "DRM is applied," and that alone solves half the problem. The other half we cannot solve — it is the vendor's domain.

So what should you do in an SI project

We can neither build nor fix DRM. What we can do is design and negotiate.

1. Is there a requirement that the server must read the document content?

If there are such requirements, you must consult the DRM owning department in the analysis stage. If you discover it after the design is finished, you either have to drop the requirement itself or need a separate budget.

2. The outcome of the consultation is usually one of three

Approach Description Caution
Server-side decryption module (SDK) Decrypt with a server library provided by the vendor Separate license and cost. Server registration required
Exception policy Allow plaintext storage for specific upload paths/accounts Security team approval is mandatory. Minimize the scope
Decrypt on the user's PC at upload Upload in plaintext from a PC that has the agent Web uploads are usually not decrypted automatically

The third is especially a trap. "The user's PC has the agent, so it will be decrypted and uploaded on its own" is mostly wrong. It is decrypted when the Office program opens it, but when the browser reads the file to upload it, depending on policy it is uploaded as ciphertext. So in the test environment you must do upload tests from a PC with real DRM applied. Developer PCs are usually exempted, so the test passes. And it blows up after launch.

3. Include the export (decryption) procedure in the requirements

If there is a business need to send DRM-protected documents outside (to partners or customers), an export approval procedure is needed. At large enterprises this happens thousands of times a month. If our system is part of that flow (for example, posting a file on a partner portal), approval integration or export API integration must be in the requirements.

A summary of adjacent concepts

If you distinguish the terms often used mixed up with DRM, you will not get lost in meetings.

Term What it does Control point
DRM Encrypts the document itself and controls viewing permissions The file
DLP Monitors and blocks information leak paths (mail, USB, web) The path
Document centralization Stores documents only on a central server, not on PCs Storage location
VDI / network separation Separates the work environment itself The environment
Watermarking Shows identifying information on prints and screens (to trace leaks) After-the-fact tracing

Sites where all five are applied at once are common. So for the single symptom "the file will not upload," there are five candidate causes. The order for narrowing the problem is:

  1. Does the same file open locally? → if it opens, the file is fine, and it is an environment problem
  2. Is the file signature normal? → if not, DRM encryption
  3. Is it also blocked via other paths (mail/USB)? → if blocked, DLP
  4. Does it happen only for particular users? → if so, permissions/policy
  5. Does it happen only on a particular network? → if so, network separation/firewall

Finally — what to leave in the logs

DRM-related outages are hard to reproduce. Because they depend on the user's PC environment. So if you log the following at the upload processing point, analysis time drops greatly.

With even the leading-bytes log alone, you can decide "is it DRM or not" after the fact. If you do not leave it, you have to get the file from the user again every time.