Hvordan lagres følsomhetsetiketter i PDF-filer? Hvordan håndteres kryptering når dokumenter eksporteres fra Office til PDF? Og hva med arkivformatet PDF/A? La oss gjøre et dypdykk i PDF-formatet!
Kort om PDF
Til forskjell fra Office-dokumenter, som i praksis er zip-containere med en mappestruktur av XML-filer, er en PDF bygget opp som en enkelt binærfil. Binærfilen består av en serie objekter som peker til hverandre via objektnumre, og PDF-lesere tolker disse objektene en etter en for å rendere dokumentet visuelt.
I PDF-standarden er innholdet organisert i ulike objekttyper, blant annet:
• /Catalog – toppobjektet som beskriver dokumentets struktur
• /Pages – en liste over alle sider
• /Page – én enkelt side
• /Contents – tegninstruksjoner for siden (tekst, grafikk, layout)
• Streams – binære datablokker som brukes til blant annet tekst, bilder og vedlegg
PDF-filer inneholder også et eget metadatalag basert på XMP (Extensible Metadata Platform). XMP-metadata lagres som XML inne i PDF-filen og brukes til å beskrive dokumentegenskaper som tittel, skaper, tidsstempler og tekniske tilleggsdata. Microsoft legger sin etikettinformasjon i dette XMP-laget, i et eget namespace kalt pdfx. Dette gjør at informasjon om hvilken følsomhetsetikett som er brukt kan leses direkte fra filen (selv når innholdet er kryptert).
Hvordan PDF-formatet ivaretar kryptering
Når en PDF-fil er kryptert ved hjelp av en følsomhetsetikett fra Microsoft Purview Information Protection (MIP), så er det RMS som står for selve krypteringen. PDF-filen får da et ekstra lag som omfatter en wrapper-side og en kryptert payload. Wrapper-siden inneholder blant annet meldingen som vises i PDF-lesere som ikke støtter MIP, mens det originale dokumentet ligger skjult i en kryptert stream. Denne streamen kan kun dekrypteres av PDF-lesere med MIP-støtte, noe som blant annet gjør de i stand til å hente dekrypteringsnøkkelen fra tenanten hvor krypteringen er påført.
Eksempel – vi åpner en RMS-kryptert PDF-fil
La oss start med å opprette et nytt dokument i Word, og merke dokumentet med følsomhetsetiketten Konfidensiell. Etiketten er konfigurert med tilgangskontroll, hvor alle tenant users har rettigheter som redaktør. Konfigurasjonen innebærer at når en bruker påfører et dokument denne etiketten, så blir dokumentet kryptert, og kun brukere i samme tenant kan dekryptere og lese innholdet.
Nå som vi har et dokument merket konfidensielt, så kan vi eksportere dokumentet til PDF. Dette bør gjøres på en Windows-maskin, da MacOS (foreløpig) ikke kan eksportere krypterte dokumenter til PDF. Nå har vi en PDF-fil som vi kan utforske.
Hvis vi nå forsøker å åpne PDF-filen i Brave eller Chrome, så ser vi følgende:
Dette er den informasjonsteksten som ligger i den ukrypterte delen av PDF-filen. Teksten er hardkodet inn i filen, og vises når en PDF-leser ikke støtter MIP. Selve dokumentinnholdet (det vi skrev i selve Word-dokumentet) er kryptert i en separat stream, men som vi ser er ikke nettleseren i stand til å hente dekrypteringsnøkkelen fra tenanten som dokumentet ble opprettet i. Microsoft Edge støtter MIP.
Hva skjer dersom vi bruker en PDF-leser som støtter MIP? En slik PDF-leser er Adobe Acrobat Reader DC. La oss installere applikasjonen, og åpne PDF-fila på nytt. Nå ser vi at vi kan logge inn:
Etter å ha oppgitt e-postadressen til en bruker i samme tenant, så kan vi godta autentiseringsforespørselen:
Når det er gjort, så får vi frem det krypterte innholdet i PDF-fila. Som vi ser, så blir dokumentinnholdet beskyttet selv etter eksport til PDF-formatet. Det er bra, da beskyttelsen skal følge innholdet, ikke formatet.
Selve dialogen vises av Adobe Reader, men autentiseringen utføres gjennom Microsofts autentiseringsbibliotek (MSAL) mot Entra ID. Etter innlogging henter Adobe Reader en RMS-lisens fra brukerens tenant og bruker denne nøkkelen til å dekryptere PDF-filen lokalt. Dette er grunnen til at dokumentet kun kan åpnes av brukere som har rettigheter i den aktuelle tenanten.
…men hva med PDF/A?
I Norge er PDF/A det offisielle arkivformatet for PDF (se riksarkivarens forskrift § 5-17 og referansekatalogen for IT-standardar). Formatet er definert i ISO 19005 og har blant annet et helt sentralt krav: PDF/A tillater ikke kryptering eller andre former for tilgangskontroll. Dette betyr at dokumenter som er RMS-kryptert ikke kan eksporteres direkte til PDF/A uten at krypteringen fjernes.
Word for Windows kan eksportere til PDF/A, men dersom dokumentet er RMS-kryptert må den først dekrypteres. Resultatet blir derfor alltid en ukryptert PDF/A-fil, og MIP-beskyttelsen følger ikke med (hvis brukeren ikke har rettigheter til å avkryptere dokumentet (det vil si eier), kan dokumentet naturligvis ikke eksporteres til PDF/A). Her ser vi hvordan vi kan velge PDF/A-formatet i Word for Windows:
Dette er viktig, fordi det er ikke ønskelig å langtidsarkivere RMS-krypterte filer i et arkivsystem. For å unngå hele greia med kryptering, så velger mange offentlige virksomheter å unngå kryptering for alle følsomhetsetiketter. Det finnes gode kompenserende tiltak, som for eksempel DLP-policyer.
PDF deep dive!
La oss utforske metadata og PDF-objekter. Vi starter med å hente ut XMP-metadata fra et par PDF-filer med exiftool. Her ser vi metadata for en ukryptert og en RMS-kryptert PDF-fil:
Vi ser tydelig at dokumentet encrypted-pdf.pdf er RMS-kryptert. En slik PDF-fil har ContentBits-verdien 9, mens en ukryptert PDF-fil har verdien 0. I tillegg får en RMS-kryptert PDF-fil automatisk tittelen «MicrosoftIRMServices Protected PDF.pdf». Dette er jo ikke en tittel vi har skrevet selv; den legges inn av MIP for å signalisere at dokumentet inneholder beskyttet innhold som bare kan åpnes av PDF-lesere som støtter MIP.
Men vent litt, hva er IRMServices? Vi har jo foreløpig tatt for oss MIP og RMS! IRM er ikke en tredje teknologi, men et eldre navn som fortsatt brukes i enkelte komponenter når PDF-filer krypteres med RMS. Adobe Reader og Microsofts egne PDF-moduler refererer fortsatt til RMS-kryptering som “IRM Services”, fordi dette var betegnelsen før MIP ble etablert som det overordnede rammeverket for etiketter og beskyttelse. Selv om dagens begreper er MIP for etiketter og RMS for kryptering, så viser metadata i PDF-filer fortsatt “MicrosoftIRMServices Protected PDF.pdf” for krypterte dokumenter. Dette er fortsatt RMS-kryptering — bare med et historisk navn i metadataen. Les mer om metadata på Microsoft Learn – Microsoft Information Protection SDK – Metadata.
Ok, la oss fortsette å analysere PDF-filene på objektnivå. Til det kan vi bruke pdf-parser. Verktøyet viser alle objektene, innholdet i streams, samt metadata. Når vi bruker pdf-parser på en RMS-kryptert PDF-fil, så kan vi tydelig se forskjellen mellom den ukrypterte wrapper-siden, som inneholder meldingen om at dokumentet er beskyttet, og den krypterte payloaden, som ligger som en binær stream utilgjengelig uten dekryptering.
La oss først utforske en ukryptert PDF-fil. Her ser vi tilsvarende metadata som vi så med exiftool (lagret i objekt 3):
Vi kan deretter se selve innholdet (lagret i objekt 5):
Når vi ser på innholdet i en ukryptert PDF-fil, så vil vi ikke se vanlig lesbar tekst slik den fremstår i Word. PDF-formatet lagrer ikke tekst som rene tegn, men som en sekvens av grafiske instruksjoner. Operatorene BT og ET markerer for eksempel start og slutt på et tekstområde, Tf setter font, Tm angir posisjon på siden, og TJ viser selve tegnsekvensen. Dette er helt normalt, og viser bare at PDF er et grafikkformat som beskriver hvordan siden skal tegnes, ikke et dokumentformat med tekststrenger slik som i Word.
La oss fortsette med å utforske en RMS-kryptert PDF-fil. Her ser vi hvordan wrapper-siden er lagret i PDF-en (objekt 7).
Vi kan se wrapper-siden (objekt 7) med teksten «Dette dokumentet bruker kryptering drevet av Microsoft Information Protection…». Riktignok litt vanskelig å se, men teksten «Dette dokument…» vises gjennom følgende instruksjoner:
[(De)22(t)-10(t)-10(e)23( )-25(d)-12(o)-15(ku)13(m)9(e)23(n)16(t)…] TJET
