Skip to content
Permalink
Browse files

Update ASiC_sikkerhet.textile

  • Loading branch information...
ogrinde committed May 16, 2014
1 parent 597e47d commit 60781b651368d1565887578799b48a668f88555b
Showing with 87 additions and 11 deletions.
  1. +87 −11 Dokumentpakke/ASiC_sikkerhet.textile
@@ -8,50 +8,126 @@ h3. Introduksjon

En forsendelse i Sikker digital post inneholder blant annet informasjon for varsling og et hoveddokument med null eller flere vedlegg.

Her beskrives hvordan dokumenter som sendes i Sikker digital post er beskyttet.
Her beskrives hvordan dokumenter og vedlegg som sendes i Sikker digital post er beskyttet.

Dokumentene og metadata relatert til dokumentene pakkes i en dokumentpakke som ivaretar dokumentenes integritet, samt integriteten til metadata relatert til dokumentene. Dokumentpakken krypteres med en symmetrisk engangsnøkkel, og den symmetriske nøkkelen krypteres med mottakerens sertifikat som hentes fra oppslagstjenesten for kontaktinformasjon.
Dokumentene og metadata relatert til dokumentene pakkes i en dokumentpakke som ivaretar dokumentenes integritet, samt integriteten til metadata relatert til dokumentene. Dokumentpakkens konfidensialitet ivaretas ved at dokumentpakken krypteres med en symmetrisk engangsnøkkel, og den symmetriske nøkkelen krypteres med mottakerens sertifikat som hentes fra oppslagstjenesten for kontaktinformasjon.

h3. Referanser

TODO: Formattering slik at (CMS) på slutten av tittelen blir med

[1] ETSI, «ETSI TS 102 918: "Electronic Signatures and Infrastructures (ESI); Associated Signature":http://www.etsi.org/deliver/etsi_ts/102900_102999/102918/01.03.01_60/ts_102918v010301p.pdf ,» ETSI, 2013-06.

[2] ETSI, «ETSI TS 103 174: "Electronic Signatures and Infrastructures (ESI); ASiC Baseline Profile":http://www.etsi.org/deliver/etsi_ts/103100_103199/103174/02.02.01_60/ts_103174v020201p.pdf ,» ETSI, 2013-06.

[3] ETSI, «ETSI TS 101 903: "Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic Signatures (XAdES)":http://www.etsi.org/deliver/etsi_ts%5C101900_101999%5C101903%5C01.04.02_60%5Cts_101903v010402p.pdf ,» ETSI, 2010-12.

[4] ETSI, «ETSI TS 103 171: "Electronic Signatures and Infrastructures (ESI); XAdES Baseline Profile":http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf ,» ETSI, 2012-03.

h3. ASiC profil for dokumentpakken brukt i sikker digital post.
[5] IETF, "RFC 5652: Cryptographic Message Syntax (CMS)_":https://tools.ietf.org/html/rfc5652 , 2009-09.

[6] IETF, "RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)_":http://tools.ietf.org/html/rfc3560 , 2003-07.

[7] IETF, "RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)_":https://tools.ietf.org/html/rfc3565 , 2003-07.

[8] IETF, "RFC 5084: Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)_":http://tools.ietf.org/html/rfc5084 , 2007-11.

h3. Integritet

Integriteten til dokumentene skal kunne valideres mange år etter mottak, og er ivaretatt ved digitale signaturer som beskrevet nedenfor. I praksis er dette en zip-fil med en gitt struktur som inneholder en digital signatur over innholdet.

h4. ASiC profil for dokumentpakken brukt i sikker digital post.

Hoveddokumentet og vedleggene pakkes sammen i en dokumentpakke sammen med noe metadata i henhold til [1], og videre begrenset i henhold til profilen definert i [2]. Ytterlige begrensninger følger nedenfor:

[2] krav 6.1 “ASiC conformance” skal være “ASiC-E XAdES”.

[2] krav 8.1 “ASiC-E Media type identification” skal være “ASiC file extension is ".asice"”

[2] krav 8.2 “ASiC-E Signed data object”. Alle filer utenfor META-INF katalogen skal være signert.

[2] krav 8.3.1 «ASiC-E XAdES signature» Det skal kun være en signatur i META-INF katalogen, med navn signature.xml. Denne signaturen skal dekke alle andre filer i beholderen, og avsenderens virksomhetssertifikat skal benyttes for signering.

[2] krav 8.3.2 “Requirements for the contents of Container” refererer til [1] 6.2.2 punkt 4b) “"META-INF/manifest.xml" if present […]”. Denne filen skal ikke være tilstede.

h3. Signatur i dokumentpakken for sikker digital post
h4. Signatur i dokumentpakken for sikker digital post

Dokumentpakken BØR være signert av "Behandlingsansvarlig":../Aktorer, men KAN signeres av "Databehandler":../Aktorer.
Dokumentpakken bør være signert av "Behandlingsansvarlig":../Aktorer, men kan signeres av "Databehandler":../Aktorer.

Signaturen skal være i henhold til [3] med basisprofilen definert i [4] (B-Level Conformance). Ytterlige begrensninger følger nedenfor:

[4] krav 5.1 «Algorithm requirements». Signeringsalgoritmen skal være "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256":http://www.w3.org/2001/04/xmldsig-more#rsa-sha256. Fingeravtrykksalgoritmen i referansene skal være "http://www.w3.org/2001/04/xmlenc#sha256":http://www.w3.org/2001/04/xmlenc#sha256. Fingeravtrykksalgoritmen i CertDigest skal være "http://www.w3.org/2000/09/xmldsig#sha1":http://www.w3.org/2000/09/xmldsig#sha1..
[4] krav 5.1 «Algorithm requirements». Signeringsalgoritmen skal være "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256":http://www.w3.org/2001/04/xmldsig-more#rsa-sha256. Fingeravtrykksalgoritmen i referansene skal være "http://www.w3.org/2001/04/xmlenc#sha256":http://www.w3.org/2001/04/xmlenc#sha256. Fingeravtrykksalgoritmen i CertDigest skal være "http://www.w3.org/2000/09/xmldsig#sha1":http://www.w3.org/2000/09/xmldsig#sha1.

[4] krav 6.2.1 «Placement of the signing certificate”. Alle sertifikater fra virkomhetsertifikatet og opp til en tiltrodd rot skal være inkludert.

[4] krav 6.2.2 “Canonicalization of ds:SignedInfo element” skal være "http://www.w3.org/2006/12/xml-c14n11":http://www.w3.org/2006/12/xml-c14n11

[4] krav 6.2.3 “Profile of ds:Reference element”. Alle dokumenter skal være med, og det er ikke lov med referanser utenfor dokumentpakken.

[4] krav 6.2.4 “Transforms within ds:Reference element”. Alle fil-referansene skal være uten transform, og referansen til SignedProperties skal være "http://www.w3.org/TR/2001/REC-xml-c14n-20010315":http://www.w3.org/TR/2001/REC-xml-c14n-20010315

[4] krav 6.3.1 “Profile of xades:SigningCertificate element”. Ingen ytterlige begrensninger.

[4] krav 6.3.2 “Profile of xades:SigningTime element”. Tidsangivelsen skal være korrekt innenfor +/- 5 sekunder.

[4] krav 6.3.3 “Profile of xades:DataObjectFormat element”. Kun MimeType og ObjectReference skal være med.

h3. Konfidensialitet

Dokumentpakken krypteres med en 256-bit AES nøkkel i modus AES/CTR/NoPadding. Det skal genereres en ny nøkkel for hver kryptering av en dokumentpakke. Teller (IV) skal starte på. IV lik null er sikkerhetsmessig ikke et problem fordi den aldri blir gjentatt ettersom nøkkelen bare brukes en gang.
TODO: Formatering i ASN.1 med for eksempel [0] skal ikke være en referanse

Integriteten til den krypterte dokumentpakken ivaretas av "Dokumentpakke":../StandardBusinessDocument/Melding/Dokumentpakke.
Dokumentpakken krypteres til mottakers sertifikat som leveres fra oppslagstjenesten. Krypteringen skal gjøres i henhold til [5] med begrensninger angitt nedenfor.

CMS starter med en sekvens av ContentInfo

ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }

Her skal følgende begrensninger gjelde:
contentType = 1.2.840.113549.1.7.3 (id-envelopedData)
content er EnvelopedData som beskrevet nedenfor.

Det er avsenders ansvar å generere en AES-nøkkel med tilstrekkelig tilfeldighet. Kilden bør være en sertifisert tilfeldig tall generator (TRNG).
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

Her skal følgende begrensninger gjelde:
version = 1
originatorInfo skal ikke være med
recipientInfos en mengde av nøyaktig en KeyTransRecipientInfo som beskrevet nedenfor
encryptedContentInfo er EncryptedContentInfo som beskrevet nedenfor
unprotectedAttrs skal ikke være med

KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }

Her skal følgende begrensninger gjelde:
version = 0
rid = issuerAndSerialNumber
keyEncryptionAlgorithm = 1.2.840.113549.1.1.7 (id-RSAES-OAEP) som spesifisert i [6]
hashFunc = { 1.3.14.3.2.26 (id-sha1), Null }
maskGenFunc = { 1.2.840.113549.1.1.8, { 1.3.14.3.2.26 (id-sha1), Null } }
pSourceFunc = { 1.2.840.113549.1.1.9, nullOctetString }

EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

Her skal følgende begrensninger gjelde:
contentType = 1.2.840.113549.1.7.1 (data) TODO: sjekk støtte for s/mime og mulighet for å angi ASiC.
contentEncryptionAlgorithm = 2.16.840.1.101.3.4.1.46 (aes256-GCM) i henhold til [8] som anbefalt, men kan også bruke 2.16.840.1.101.3.4.1.42 (aes256-CBC) i henhold til [7].

Ved bruk av aes256-CBC skal padding gjøres i henhold til [5], kapittel 6.3.

Integriteten til den krypterte dokumentpakken ivaretas av "Dokumentpakke":../StandardBusinessDocument/Melding/Dokumentpakke.

AES-nøkkelen krypteres til mottakers sertifikat som beskrevet i "Dokumentpakke":../StandardBusinessDocument/Melding/Dokumentpakke.
Det er avsenders ansvar å generere en AES-nøkkel med tilstrekkelig tilfeldighet. Kilden bør være en sertifisert generator for tilfeldige tall (TRNG).


0 comments on commit 60781b6

Please sign in to comment.
You can’t perform that action at this time.