Reading Time: 4 Minutes

Azure Information Protection – AIP

In this Article
    Driven by the security requirements of customers when storing files in the Azure Cloud, Microsoft provides a protection mechanism – Azure Information Protection (AIP). Such protected files are also increasingly found in the SAP DMS of our customers, where they cause conversion errors or cannot be printed via PLOSSYS®. Microsoft Information Protection (MIP) is very similar to AIP. This article describes what we know so far about AIP and MIP and how our solution concepts look like.

    Theory …

    With AIP (also used as a synonym for MIP in the following) an Office file is encrypted proprietarily. This is not a known cryptographic procedure with certificates. For decryption, an SDK from Microsoft is available and also a client (Unified Labeling Client) to a Microsoft server.

    For the storage of the encrypted content and the accompanying information the well-known Structured Storage Format is used (https://en.wikipedia.org/wiki/COM_Structured_Storage). From a non-encrypted part of this data, XML files can be read which additional information the file in question has, such as the classification level (“internal”, “top secret”, …). Reading this accompanying information can be done via Microsoft SDK or in plain text. Companies using this system can even define their own classification levels, along with the corresponding texts in different languages. The languages are addressed via standardized IDs. The accompanying information is also easily machine-readable thanks to XML and can be used for automated responses to the classification levels.

    The marking with a classification level is called “labeling” by Microsoft.

    Microsoft also supports the encryption of PDF files with its AIP SDK. If such a PDF file is opened in Acrobat Reader, the only visible message is that the file is encrypted and that a corresponding add-in from Microsoft should be installed in Acrobat Reader. This visible additional text is the content of an additionally created envelope PDF. The original, now encrypted PDF file is attached to this envelope PDF.

    Some image formats are also supported by AIP.

    Encryption and decryption are user-specific. There is also a privileged super user (system user).

    … and Practice

    The user normally does not notice that he is working with encrypted documents. He can click on a file as usual and it will be opened in the assigned application.

    In the background, the application establishes a connection to the AIP server and checks the user’s authorization. Only if the permissions are missing, a corresponding message is displayed.

    In the application itself, an additional menu is displayed with which the “labels” can be managed.

    Our offers

    AIP is new. We are still at the beginning of developing suitable tools and solutions for handling AIP-protected files.

    There is a module for reading the label information. This module can be used, for example, in the context of conversion­servers to return a dedicated error to the ordering system. The source application must then be able to handle it. This module is intended for our conversion server in the SAP environment.

    Automatic decoding for conversion is currently not yet available. Here we are still waiting for feedback on how our customers want to build their security concepts in this regard.

    The output of protected files via PLOSSYS can be implemented project specific. For this the output job must be provided with a system user and the “Unified Labeling Client” must be installed on the PLOSSYS server. This decoding at the output still has project character. There is still too little experience with the stability of such a solution. We are affected here by changes by Microsoft, which also existed in the recent past.

    Further solutions will follow. We are happy to respond to our customers’ requirements here.

    Special environments

    We have the opinion that in the SAP environment, SAP’s authorization concept is responsible for adequately protecting originals in the SAP DMS. Additional file protection would also contradict PDF/A. Outside SAP DMS, for example after download etc., additional document protection may be appropriate. With our experience from previous projects with other DRM systems, we are able to integrate an AIP encryption in SAP in such a way that all files worth protecting are encrypted when exiting SAP.

    In a real customer case, unprotected PDFs were created unnoticed from protected Office files via a SEAL Office converter. The conversion jobs were sent in the context of a super user and the customer had installed the Unified Labeling Client on the conversion server. The Office installation did on the conversion server what it would have done on a client: it obtained permission to decrypt via the labeling client.