Watermarks i PDF (Re: Sv: Validering av filformater)
Aamot Software
ole at aamot.software
Tue Jan 3 08:01:55 CET 2023
Hei igjen,
Her er kode for å finne inverse hash'er i et XML-dokument, jeg regner
med at signaturen til
PDF-dokumenter kan finnes på samme måte, bare ved å bytte ut
kanoniserende funksjon fra XML
til PDF:
Source (HashSignature.java)
public String getXMLInvHash(String xmlDocument) {
String xmlHasHString = "";
try {
Transformer transformer = this.getTransformer();
ByteArrayOutputStream byteArrayOutputStream = new
ByteArrayOutputStream();
StreamResult xmlOutput = new
StreamResult(byteArrayOutputStream);
transformer.transform(new StreamSource(new
StringReader(xmlDocument)), xmlOutput);
String canString =
canonicalizeXml(byteArrayOutputStream.toByteArray());
byte[] shaByte = hashStringToBytes(canString);
xmlHasHString = Base64.getEncoder().encodeToString(shaByte);
} catch (TransformerException e) {
e.printStackTrace();
}
return xmlHasHString;
}
private String canonicalizeXml(final byte[] xmlDocument) {
String canonicString = "";
try {
Init.init();
Canonicalizer canon =
Canonicalizer.getInstance("http://www.w3.org/2006/12/xml-c14n11");
// System.out.println("Can : " + new
String(canon.canonicalize(xmlDocument)));
canonicString = new String(canon.canonicalize(xmlDocument));
} catch (ParserConfigurationException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} catch (SAXException e) {
e.printStackTrace();
} catch (InvalidCanonicalizerException e) {
e.printStackTrace();
} catch (CanonicalizationException e) {
e.printStackTrace();
}
return canonicString;
}
private Transformer getTransformer() {
TransformerFactory transformerFactory = null;
Transformer transformer = null;
try {
transformerFactory = TransformerFactory.newInstance();
transformer = transformerFactory.newTransformer();
transformer.setOutputProperty("encoding", "UTF-8");
transformer.setOutputProperty("indent", "no");
transformer.setOutputProperty("omit-xml-declaration",
"yes");
} catch (TransformerException e) {
e.printStackTrace();
}
return transformer;
}
private byte[] hashStringToBytes(String input) {
MessageDigest digest = null;
try {
digest = MessageDigest.getInstance("SHA-256");
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}
final byte[] hash =
digest.digest(input.getBytes(StandardCharsets.UTF_8));
return hash;
}
Den 2023-01-03 07:39, skrev Aamot Software:
> Hei,
>
> Både Adobe Acrobat og LibreOffice har en funksjon for å skrive
> Watermarks i PDF'er.
>
> Se
> <URI:https://helpx.adobe.com/no/acrobat/using/add-watermarks-pdfs.html>
> og
> <https://www.libreofficehelp.com/how-to-add-watermark-in-libreoffice-writer/>
>
> Se eksempel på et PDF-dokument med teksten ("GNOME Foundation") i
> grønn Watermarks skrevet fra LibreOffice på
> <URI:https://www.aamot.software/Aamot_CV_2023.pdf>
>
> Aspose Java API har et programmertbart Java-grensesnitt for å skrive
> Watermarks i PDF'er. Se
> <URI:https://blog.aspose.com/pdf/add-watermark-to-pdf-using-java/#Java-API-to-Add-Watermark-to-PDF>
>
> Source (pom.xml):
>
> <repository>
> <id>AsposeJavaAPI</id>
> <name>Aspose Java API</name>
> <url>https://repository.aspose.com/repo/</url>
> </repository>
>
> <dependency>
> <groupId>com.aspose</groupId>
> <artifactId>aspose-pdf</artifactId>
> <version>21.6</version>
> </dependency>
>
> Source (Watermarks.Java):
>
> // Load PDF document
> Document doc = new Document("Aamot_CV_2022.pdf");
>
> // Create a formatted text
> FormattedText formattedText = new FormattedText("GNOME Foundation",
> java.awt.Color.GREEN, FontStyle.Courier, EncodingType.Identity_h,
> true, 40.0F);
>
> // Create watermark artifact and set its properties
> WatermarkArtifact artifact = new WatermarkArtifact();
> artifact.setText(formattedText);
> artifact.setArtifactHorizontalAlignment (HorizontalAlignment.Center);
> artifact.setArtifactVerticalAlignment (VerticalAlignment.Center);
> artifact.setRotation (90);
> artifact.setOpacity (0.5);
> artifact.setBackground (false);
>
> // Add watermark to the first page of PDF
> doc.getPages().get_Item(1).getArtifacts().add(artifact);
>
> // Save watermarked PDF document
> doc.save("Aamot_CV_2023.pdf");
>
> Mvh,
> Ole
>
> Den 2022-12-19 11:41, skrev Thomas Sødring via nikita-noark:
>> Hei,
>>
>> Merk! Jeg kan ikke nok om PDF/A til å uttale med bastant. Ta det jeg
>> sier med en
>> klype salt. Jeg synes spørsmålet er interessant og kaster ut mine
>> tanker
>> og håper andre kan komme med innspill.
>>
>> Når jeg leser om PDF/A og signaturer (overfladisk) så ville jeg
>> trodd at dette
>> ikke ville være et problem. Jeg forstod det slik at signaturer dekket
>> et sett
>> av innhold i dokumentet og selve signaturen ligger i en "lomme" i PDF
>> filen.
>>
>> I teorien skal det være mulig å flytte innholdet og signaturen inn i
>> en PDF/A
>> fil, men kun dersom det ikke ble gjort endringer til innhold feks et
>> problem med
>> en font / bilde. Det er vel avhengig av hvor mye konvertering som må
>> skje.
>>
>> En stund tilbake ble det sagt at signaturer er noe fagmiljøet ikke
>> har tenkt over i det
>> hele tatt. Det er ikke sant da signaturer er noe som er beskrevet i
>> Noark og
>> løsningen der er jeg delvis enig i.
>>
>> Noark håndterer problemstillingen med at Noark velger at du kun skal
>> dokumentere
>> hvorvidt dokumentets signatur stemte under danningen. Noark sin
>> XML/XSD gjør
>> ikke plass for noe teknisk bevaring av PKI infrastrukturinformasjon.
>>
>> <xs:complexType name="elektroniskSignatur">
>> <xs:sequence>
>> <xs:element name="elektroniskSignaturSikkerhetsnivaa"
>> type="n5mdk:elektroniskSignaturSikkerhetsnivaa"/>
>> <xs:element name="elektroniskSignaturVerifisert"
>> type="n5mdk:elektroniskSignaturVerifisert"/>
>> <xs:element name="verifisertDato" type="n5mdk:verifisertDato"/>
>> <xs:element name="verifisertAv" type="n5mdk:verifisertAv"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> (ref:
>> https://github.com/arkivverket/schemas/blob/master/N5/v5.0/arkivstruktur.xsd#L566)
>>
>>
>> Noark 5v4 hadde en restriksjon på elektroniskSignaturVerifisert som
>> ble borte i
>> Noark 5v5.
>>
>> <xs:restriction base="xs:string">
>> <xs:enumeration value="Signatur påført, ikke verifisert"/>
>> <xs:enumeration value="Signatur påført og verifisert"/>
>> </xs:restriction>
>>
>> I teorien kan det i Noark 5v5 stå "Signatur påført, verifisert og
>> ikke verifisert"!
>>
>> Denne generelle tilnærmingen er noe jeg opplever som både positivt
>> og negativt.
>> Det er positivt at Noark har valgt hvordan signaturer skal håndteres
>> og her er
>> det en fiks ferdig tilnærming fagmiljøet kan diskutere for å komme
>> fram til en
>> best practice. Positivt også at det er så enkelt. Men den verdien i
>> elektroniskSignaturVerifisert kan bli viktig senere.
>>
>> Det vi tidligere har diskutert i nikita prosjektet er hvorvidt
>> organisasjoner
>> burde bevare den offentlig nøkkelen som ble brukt til å verifisere
>> signaturen,
>> eller ikke. Fra en etterprøvbarhetsperspektiv så er svaret til det
>> JA. Depot
>> burde bevare de offentlig nøklene som er brukt. Men slik er det ikke
>> i Noark og
>> den delen av en "chain-of-custody" skal bevist kastes. Jeg mistenker
>> at grunnen
>> Noark gjør det slikt er fordi Noark ikke skal styre for mye dette da
>> det kan
>> være noen uante kostnader her. Altså at depot ikke skal bry seg om
>> autentisitet
>> på dette nivået.
>>
>> Tid vil være en utfordring dersom vi bevarer slike nøkler med
>> dokumentet. Vi må
>> også bevare hvilken algoritme og håpe at det fortsatt vil være en
>> implementasjon
>> tilgjengelig som gjør at vi kan verifisere signaturen på en
>> uavhengig vis.
>>
>> Dette med uavhengig vis er viktig synes jeg! Jeg mistenker at Norge
>> vil bruke
>> informasjonssiloer og bli mer og mer avhengig av leverandører for
>> ting
>> som verifisering av signatur. Da vil depot ha et problem dersom det
>> er viktig å
>> sikre etterprøvbarheten til signaturen. Dersom etterprøvbarheten er
>> viktig så
>> må depot besitte kompetanse (enkelt) og infrastruktur, noe som ikke
>> er enkelt
>> om det er en proprietær tjeneste der ting er skjult.
>>
>> Noark løser problemet ditt dersom du kan leve med at depot ikke
>> trenger å
>> senere verifisere signaturer på PDF/A variantene. Du trenger bare å
>> verifisere
>> at dokumentets signatur er gyldig og så konvertere til PDF/A.
>>
>> Dersom vi ser litt mer på dette så er det vel slik at de PDF/A filer
>> burde være
>> identifisert med PUID fmt/476 (2a) eller fmt/477 (2b), men det du
>> etterspør er
>> egne PUID for PDF/A filer som inneholder en signatur som kan
>> verifiseres.
>>
>> https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1263
>>
>> https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1264
>>
>>
>> fmt/276 er danningsformatet for PDF 1.7 (slik jeg forstår det) så
>> det er ingen
>> forsøk på å få dette til PDF/A.
>>
>> https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1016
>>
>>
>> Jeg husker jeg snakket med en leverandør en gang om mismatch i
>> registrerte
>> filformater i databasen og de fortalte at det var en nesten umulig
>> oppgave å
>> vite om ting faktisk var i PDF/A. Jeg ville håpet at vi er kommet
>> videre siden
>> da!
>>
>> Når det gjelder spørsmål 1:
>>
>> Først vil jeg trekke oppmerksomheten til en diskusjon i Noark på
>> github
>>
>> https://github.com/arkivverket/noark5-standard/pull/99#issuecomment-814962618
>>
>>
>> der det framkommer at noen depot institusjoner ikke ønsker å beholde
>> flere
>> kopier av et dokument. Greit å ha en slik perspektiv i bakhodet når
>> man
>> diskuterer dette.
>>
>> "Vil bruk av metadatafeltene elektroniskSignatur i Noark kunne
>> erstatte
>> bevaringen av en uendret versjon?"
>>
>> Min forståelse er at du har et signert dokument i vanlig PDF, ikke
>> PDF/A. Så
>> denne produksjonsformat PDF filen kan inneholde fonter og annet
>> informasjon som
>> er lenket til operativsystemet som skapte PDF dokumentet. Dette er noe
>> som vil
>> ha utfordringer når det gjelder bevaring. Når du konverterer til
>> PDF/A blir
>> signaturen feil. Så du er nødt til å konvertere til PDF/A, men du
>> mister
>> signaturen. Da må du ivareta signaturen på en måte. Her kan Noark
>> sin metadata
>> brukes til å bekrefte at signaturen stemte. Men egentlig kan du vel
>> bevare begge
>> deler, men produksjonformat PDF'n vil miste noe av nytteverdien det
>> øyeblikket det
>> ikke er mulig å verifisere signaturen og dersom du er avhengig av en
>> tjeneste
>> for å verifisere så vil det skje når tjenesten legges ned /
>> nøkler ikke er
>> tilgjengelig.
>>
>> Merk! Jeg kan ikke nok om postens tjeneste for å vite om offentlig
>> nøkler er fritt
>> tilgjengelig for nedlasting, hva skjer dersom en privatnøkkel blir
>> lekket og det
>> er tilbakekalling osv.
>>
>> Hva som vil gi best integritet over tid? Jeg tror etterprøvbarheten
>> og mulighet
>> til å verifisere dokumentet når som helst vil være det som gir best
>> integritet.
>> Dersom det ikke er mulig så vil det kanskje være en sporbar prosess
>> på
>> verifikasjonen som er best. At det registreres at signaturen er
>> verifisert,
>> av hvem og når. "Hvem" er vel bare et programvare.
>>
>> Spørsmål 2:
>>
>> Litt beslektet diskusjon fra arkade5:
>>
>> https://github.com/arkivverket/arkade5/issues/97
>>
>> At Pronom ikke er ønskelig i danning, det er en depot anliggende. I
>> nikita ønsker
>> jeg å bruke relevant verktøy for å identifisere pronomkoder så
>> fort som mulig.
>> Jo mer kontroll du har, jo bedre. Du er inn på det når du etterspør
>> pronomkoder
>> for å skille signert/ ikke signert PDF/A
>>
>> Jeg vet at Petter Reinholdtsen jobbet med å få sosi koder inn i
>> pronom listen
>> og lagde en M701-verdikatalog for Noark 5 (Tjenestegrensesnitt)
>>
>> https://gitlab.com/petterreinholdtsen/m701-noark5-katalog
>>
>> Dette er vel et spørsmål som må løftes høyere. Jeg har ingen
>> tillit at det
>> finnes noen hos Arkivverket som har evnen eller kunnskap til å gjøre
>> denne
>> jobben så jeg er usikker hvem som er riktig instans.
>>
>> Det må være mulig å gjøre dette, men er det så viktig å ha egen
>> pronom kode for
>> en PDF/A som er signert? Jeg tror JA, det er veldig viktig. Det er
>> litt som
>> pronomkoder for docx. Det er interessant og viktig å vite om du har
>> docx filer med PUID fmt/494 fordi de er kryptert!
>>
>> -------------------------
>>
>> Fra: nikita-noark <nikita-noark-bounces at nuug.no> på vegne av Thomas
>> Sødring via nikita-noark <nikita-noark at nuug.no>
>> Sendt: torsdag 15. desember 2022 09:40
>> Til: nikita-noark at nuug.no <nikita-noark at nuug.no>
>> Emne: Vs: Validering av filformater
>>
>> Hei,
>>
>> Denne kom i innboksen min i går kveld fra Pål Mjørlund ved
>> Innlandet fylkesarkiv og er et tematikk som jeg synes er interessant
>> og relevant her på listen. Jeg har litt dårlig tid med sensur
>> akkurat nå, men tenkte å svare her og la andre kommentere dersom de
>> ønsker det.
>>
>> -- start --
>> Mange har nå gått over til fullelektronisk arkivering av
>> dokumenter. I en del tilfeller gjelder dette også avtaler som har
>> blitt sendt til digital signering. Jeg oppfatter at de fleste
>> kommunene benytter den nasjonale fellesløsningen til dette, og at det
>> dermed er postens signeringsportal som blir brukt for selve
>> signeringsprosessen. Jeg antar at du har kjennskap til løsningene og
>> teknologien, men dokumentasjon på løsningen finnes her:
>> https://signering-docs.readthedocs.io/en/latest/index.html [1] . Dette
>> betyr at det allerede finnes en del dokumenter i sak/arkivløsningene
>> som inneholder en digital signatur (basert på PAdES og XAdES).
>>
>> Jeg har gjort noen kontroller i forhold til dokumenter som har blitt
>> arkivert med avansert digital signatur, og oppdager at disse
>> dokumentene heller ikke validerer som godkjent arkivformat. Dette har
>> vært kjent hos Arkivverket og det ble på et møte sagt at dersom det
>> kun er signaturen som avviker fra PDF/A-2, så godkjennes signerte
>> PDF-dokumenter. Dette er imidlertid ikke helt enkelt. Dokumentene som
>> jeg finner i sak/arkivløsningen fremstår dessverre ikke som PDF/A i
>> det hele tatt, men som PDF 1.7 (pronom: fmt/276). Dette gjelder også
>> dokumenter som var konvertert til PDF/A før de ble sendt til
>> signering. Jeg har ikke funnet noen egen pronom-kode som viser at
>> dette dokumentet inneholder en digital signatur, selv om det
>> sannsynligvis burde være mulig å identifisere signaturen inne i
>> dokumentet.
>>
>> Bekymringen min er derfor i forhold til videre håndtering av disse
>> dokumentene. Den digitale signaturen kan kun bekreftes så lenge filen
>> er uendret. Dersom vi produserer PDF/A av et signert dokument vil det
>> ikke være mulig å validere signeringen lenger. Denne utfordringen
>> kan komme i forbindelse med produksjon av arkivuttrekk, men også i
>> konverteringsprosesser som skjer i et arkivdepot for å vedlikeholde
>> arkivdata.
>>
>> Jeg har egentlig to hovedspørsmål:
>>
>> Spørsmål 1:
>> I Noark-løsninger kan det være flere måter å håndtere digitale
>> signaturer. I de uttrekkene vi har mottatt, har jeg så langt ikke
>> sett at metadatafeltet elektroniskSignatur har blitt benyttet (M507,
>> M508, M622 og M623). I mitt hode kunne en slik kontroll være
>> automatisert i en løsning som benytter signeringsportalen. Jeg har
>> imidlertid ikke fått signaler om at noen løsninger støtter en slik
>> kontroll.
>> Flere opererer med flere varianter (eller bruker betegnelsen
>> «versjoner») av dokumentet – slik at løsningen kan lagre både en
>> arkivvariant og en signert variant. Det er imidlertid ikke praktisert
>> å ta med flere av disse variantene i uttrekk. Vi ser at behovet for
>> flere varianter er økende, ved at du gjerne skal ha en offentlig
>> variant (i forhold til meroffentlighet og/eller publisering på
>> postjournal hvor vi nå får krav om PDF/UA). Vil bruk av
>> metadatafeltene elektroniskSignatur i Noark kunne erstatte bevaringen
>> av en uendret versjon av det signerte dokumentet og hvilken løsning
>> vil gi best integritet over tid?
>>
>> Spørsmål 2:
>> Vi ønsker at en dokumentanalyse basert på PRONOM skal være
>> grunnlaget for å gjennomføre en dokumentkonvertering. Vi oppfatter
>> at filnavn og mime-type er mer utbredt grunnlagsdata i dag. Dersom
>> signerte dokumenter hadde hatt egne PRONOM-koder ville det vært
>> betydelig enklere å bevare originalversjonen av et signert dokument.
>> Har du noen formening om hvor enkelt det er å få definert de
>> signerte PDF-dokumentene inn som egne innføringer i
>> PRONOM-registeret, og vil det egentlig være nødvendig?
>>
>> -- slutt --
>>
>> Links:
>> ------
>> [1]
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsignering-docs.readthedocs.io%2Fen%2Flatest%2Findex.html&data=05%7C01%7Ctsodring%40oslomet.no%7Cac65966482e246c1243008dade780d3a%7Cfec81f12628645508911f446fcdafa1f%7C0%7C0%7C638066905256161256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cYLBYsZydx55UDc1VEssaSQkWcPWQ%2FPmkkiBlfLf%2BnI%3D&reserved=0
>> _______________________________________________
>> nikita-noark mailing list
>> nikita-noark at nuug.no
>> https://lists.nuug.no/mailman/listinfo/nikita-noark
> _______________________________________________
> nikita-noark mailing list
> nikita-noark at nuug.no
> https://lists.nuug.no/mailman/listinfo/nikita-noark
--
Best,
Ole Aamot
Aamot Software Founder and Developer - aamotsoftware.com
www.gnomeradio.org www.gingerblue.org www.gnomevoice.org
004741732002
More information about the nikita-noark
mailing list