Ta med din egen Auditor Cloud HSM-attest

Utstedelse av digitale sertifikater for utvidet valideringskodesignering eller Adobe-dokumentsignering krever gangivelse av en nøkkel med visse sikkerhetsegenskaper. Når den genereres, må nøkkelen flagges som "sensitiv" (som betyr at nøkkelen ikke kan vises i klartekst) og, enda viktigere, ikke-eksporterbar (kan ikke avsløres selv når den er kryptert) fra HSM. Det er flere veier å følge for denne prosedyren, som å få et sikkert token fra SSL.com med forhåndsinstallerte sertifikater. Denne artikkelen fokuserer på tilfellet der klienter velger å bruke sin egen fysiske HSM- eller sky-HSM-konto og ansetter en kvalifisert fagperson etter eget valg for å attestere riktig utførelse av denne prosessen.

Dokumentsignering, kodesignering, eSealing og mer med eSigner! Klikk nedenfor for mer informasjon.

FINN UT MER

Hva er attestasjon?

Før SSL.com kan signere og utstede EV-kode signering eller Adobe-Trusted Document Signing-sertifikater, må vi først innhente bevis på at kundens private signeringsnøkkel er generert av og er sikkert lagret i en FIPS 140-2 nivå 2 (eller høyere) sertifisert enhet, som den ikke kan eksporteres fra. Handlingen med å bevise at en privat nøkkel oppfyller disse kravene er kjent som attestasjon. De nøyaktige prosedyrene for attestering av privatnøkkel varierer mellom enheter og databehandlingsplattformer i skyen.

Noen tjenester, som Google Cloud HSM, gi ekstern attestering ved å utstede et unikt sertifikat for hver HSM som brukes, som kombinert med det unike sertifikatet utstedt av HSM-produsenten er nok til å gi sikkerhet for at den genererte nøkkelen har de nødvendige attributtene og er PKCS #11-kompatibel. En slik attestasjon anses som tilstrekkelig bevis for at SSL.com kan sikre at nøkkelen er kvalifisert.

Imidlertid er det tjenester, spesielt AWS, som ikke gir ekstern nøkkelattestering. I dette tilfellet gjøres attestasjonen ved en manuell prosedyre som kalles Key Generation Ceremony (KGC). KGC krever validering fra en revisor som har høy kompetanse på området. Kunden kan bruke en intern ekspert fra SSL.com, men kan også velge å bruke en uavhengig fagperson etter eget valg. Dette omtales som Bring Your Own Auditor (BYOA). For å sikre at prosessen gir tilstrekkelig validering, må følgende felt kontrolleres:

  • Kvalifiseringen til den valgte profesjonelle (revisor) som skal gi en skikkelig KGC
  • KGC forberedelse og utførelsesprosess
  • Minimumskravene som bør kontrolleres og rapporteres av revisor

KGC-prosess: Utarbeidelse og retningslinjer

BYOA er et gyldig alternativ for klienter, men det krever grundig forberedelse, ellers er det en betydelig risiko for avvisning av den genererte nøkkelen. Dette kan skje hvis enheten som brukes ikke er kompatibel, eller revisor ikke er kvalifisert, eller revisors rapport ikke dekker prosessens krav. I et slikt tilfelle må seremonien og vitneforklaringen gjentas, noe som resulterer i ekstra kostnader og forsinkelser for klienten. 

For å unngå slike scenarier, kommuniserer SSL.coms kundestøtte- og/eller valideringsspesialister med kunden før KGC for å gi veiledning og sikre følgende:

  • Revisor er godkjent etter kriteriene beskrevet nedenfor
  • Kravene til seremoniforberedelsene og seremoniens manus er klare og fulgt grundig, slik at KGC-miljøet er godt forberedt
  • Eventuelle restriksjoner og/eller BYOA-spesifikke vilkår og betingelser er klare og akseptert av kunden

Kvalifisering av KGC-revisor

Kunder som ber om EV Code Signing eller Adobe-Trusted Document Signing-sertifikater kan presentere sertifikatsigneringsforespørselen (CSR) og en bekreftelse fra en uavhengig fagperson (BYOA) på at nøkkelparet ble generert og lagret i en godkjent HSM, under et godkjent driftsmiljø og i samsvar med alle PKCS #11-attributter.

SSL.com har satt en rekke kriterier for å sikre kompetansen og etikken til fagpersonen som kunden velger. Disse kriteriene, som også brukes til å evaluere og godkjenne SSL.coms tilknyttede revisorer, er på plass for å sikre sikkerheten og samsvaret med signeringsproduktet (EV Code Signing eller Adobe-Trusted Document Signing-sertifikat).

Kriteriene som vurderes for aksept eller avvisning av sertifisering fra en revisor er:

  • Teknisk kompetanse: Revisor må være kvalifisert innen digital sertifisering og cybersikkerhet
  • Revisjonskompetanse: Revisor må bevise kvalifikasjonen til sin revisjonskapasitet gjennom en passende personlig sertifisering eller profesjonell kapasitet (f.eks. Webtrust/ETSI-revisor, Cloud Security Alliance CCAK).
  • etikk: En sjekk av at det er på plass en bindende etikkkodeks, f.eks. som en del av revisors sertifisering.
  • Evnen til å verifisere revisorinformasjonen ovenfor: En sjekk mot en offentlig kilde (f.eks. revisorregister) for å verifisere sertifiseringen.

Disse kriteriene kontrolleres av SSL.com-valideringsspesialister før de blir akseptert. SSL.com opprettholder en liste over BYOA-godkjente sertifiseringer for kriteriene ovenfor, sammen med en liste over tilknyttede revisorer for kundenes bekvemmelighet. 

Denne informasjonen utleveres til kunden under forberedelsesfasen. For mer informasjon, vennligst kontakt support@ssl.com

Krav til KGC-attest

Forberedelsesfasen er avgjørende for å unngå uhell i seremonien som kan føre til ekstra kostnader og forsinkelser. Kundeservicen i SSL.com sikrer at alle revisjonskrav blir kommunisert til både kunden og den kvalifiserte revisoren før et seremonimanus velges. For ytterligere å hjelpe, har SSL.com utarbeidet materiale for å støtte AWS Cloud HSM, for eksempel krav til seremoniforberedelse og et seremoniskript, som er tilgjengelig ved å kontakte support@ssl.com under forberedelsesfasen. 

Klienten kan velge å lage sitt eget manus gjennom Qualified Auditor (QA), men i dette tilfellet anbefaler vi på det sterkeste at seremoniskriptet gjennomgås og godkjennes av våre egne ingeniører før bruk.

I alle fall må den kvalifiserte revisor personlig verifisere og attestere følgende, angående seremonien for generering av private nøkkeler:

  • Private Key Material ble laget i en HSM-kompatibel med minst FIPS 140-2 nivå 2 og fungerer i minst FIPS 140-2 nivå 2-modus.
  • HSM og fastvaren som ble brukt i seremonien var ekte og fastvareversjonen er ikke assosiert med noen kjente sårbarheter
  • Programvaren som ble brukt til seremonien var offisiell HSM-programvare levert av produsenten, og dens integritet ble verifisert av QA
  • All kommunikasjon med HSM under nøkkelgenereringsprosessen ble kryptert og gjensidig autentisert via kryptografiske midler
  • Private Key Material ble opprettet inne i HSM og ble ikke importert
  • Privat nøkkelmateriale er ikke merket som uttrekkbart (PKCS #11-attributt "CKA_EXTRACTABLE/CKA_EXPORTABLE") og har aldri vært det.
  • Privat nøkkelmateriale er merket som sensitivt (PKCS #11 attributt "CKA_SENSITIVE") og det har det alltid vært.
  • Tilgang til det genererte nøkkelmaterialet krever brukerautentisering
  • QA var tilstede, har fulgt alle seremoniprosessene, og det var ingen mistanke eller bevis for stygt spill.

I tillegg til kravene ovenfor, bekrefter kvalitetssikringen at abonnentens driftsmiljø oppnår et sikkerhetsnivå som minst tilsvarer det til FIPS 140-2 nivå 2.

konklusjonen

BYOA er et gyldig og nyttig alternativ for tilfeller der ekstern attestering ikke er tilgjengelig for Extended Validation Code Signing og Adobe Approved Trust List-sertifikater. SSL.com sørger for at kundene er grundig forberedt på prosedyren og får støtte på toppnivå i tilfelle de benytter seg av dette alternativet. 

Twitter
Facebook
Linkedin
Reddit
Epost

Hold deg informert og sikker

SSL.com er en global leder innen cybersikkerhet, PKI og digitale sertifikater. Registrer deg for å motta de siste bransjenyhetene, tipsene og produktkunngjøringene fra SSL.com.

Vi vil gjerne ha tilbakemeldinger

Ta vår spørreundersøkelse og fortell oss dine tanker om ditt nylige kjøp.