Bescherm de vertrouwelijkheid en integriteit van gevoelige informatie met GO-ITS 25.12

Het Government of Ontario Information Technology Standards (GO-ITS)-programma stelt de richtlijnen, normen en werkwijzen vast waaraan ministeries van de openbare dienst van Ontario en hun leveranciers zich moeten houden. GO-ITS 25.12, Beveiligingsvereisten voor het gebruik van cryptografie , is de norm die elk ministerie, agentschap en derde partij die met gegevens van de overheid van Ontario werkt, precies vertelt welke cryptografische algoritmen, sleutellengtes en protocollen zijn goedgekeurd om de vertrouwelijkheid en integriteit van gevoelige informatie te beschermen.

In de norm zijn eisen die met 'moet' zijn geformuleerd verplicht, en eisen die met ' zou moeten' zijn geformuleerd aanbevelingen. GO-ITS 25.12 is van toepassing op ministeries van de overheid van Ontario, voormalige agentschappen van Bijlage I en IV, cloudserviceproviders en elke leverancier of derde partij die een contract heeft met de overheid van Ontario en die informatie van de openbare dienst van Ontario creëert, opslaat, verzendt of verwerkt.

Gepubliceerd: maart 2022. Bijgewerkt: augustus 2026. Beoordeeld door het Compliance Advisory-team van Encryption Consulting.

Wat zijn de vereisten voor GO-ITS 25.12?

GO-ITS 25.12 vereist dat gevoelige overheidsinformatie van Ontario in elke fase wordt beschermd met behulp van goedgekeurde cryptografische algoritmen: creatie, opslag, distributie, gebruik, intrekking, vernietiging en herstel van de betrokken sleutels. De vereisten zijn onderverdeeld in verschillende gebieden, en elk gebied is gekoppeld aan een concrete operationele controle in plaats van een vaag principe.

• Onderwijs en training. Technisch personeel dat systemen ontwikkelt, implementeert of beheert die gebruikmaken van cryptografie, moet de vereisten van de standaard begrijpen voordat ze met productiesystemen aan de slag gaan.
• In de opslag opgeslagen informatie. Gevoelige gegevens moeten in rusttoestand versleuteld worden, en gegevens die langer dan twee jaar worden bewaard, moeten worden versleuteld met een encryptiemethode die geschikt is voor een omgeving met een hoog risico. Mobiele apparaten moeten gebruikmaken van volledige schijfversleuteling, en gevoelige velden moeten op kolom- of celniveau worden versleuteld voordat ze een gegevensopslagplaats bereiken.
• Communicatiebeveiliging. Gevoelige informatie moet tijdens de overdracht worden versleuteld en de integriteit ervan moet worden geverifieerd met een goedgekeurde berichtauthenticatiecode of een digitale handtekening met een nauwkeurige, betrouwbare tijdstempel.
• Cryptografie-implementatie. Applicaties moeten een goedgekeurde generator voor willekeurige of pseudo-willekeurige getallen gebruiken, certificaten valideren voordat ze worden vertrouwd, onversleutelde gegevens direct na gebruik uit de cache of het tijdelijke geheugen verwijderen en beveiligingstests en -evaluaties (STE) doorstaan ​​voordat ze live gaan.
• Bescherming van cryptografisch materiaal. De toegang tot sleutels is beperkt tot geautoriseerde gebruikers en services, de sleutelbeveiliging is afhankelijk van de gevoeligheid van de gegevens en het genereren van sleutels moet plaatsvinden op een goedgekeurde softwaremodule of een hardwarebeveiligingsmodule (HSM), op locatie waar de informatie zeer gevoelig is.

Wie moet voldoen aan GO-ITS 25.12?

GO-ITS 25.12 is van toepassing op een bredere kring dan alleen de ministeries die de betalingen verrichten. Iedereen die via een contract toegang heeft tot gegevens van de openbare dienst van Ontario, erft de verplichtingen van deze norm.

• Ministeries van de regering van Ontario en voormalige agentschappen van Bijlage I en IV.
• Externe dienstverleners en systeemintegratoren die onder contract werken voor de overheid van Ontario.
• Cloudserviceproviders die de werklast of data van de openbare dienst van Ontario hosten.
• Elke organisatie die informatie van de overheid van Ontario creëert, opslaat, verzendt of verwerkt, ongeacht waar die verwerking fysiek plaatsvindt.

In de praktijk betekent dit dat een leverancier die inschrijft op een overheidscontract in Ontario, tijdens de aanbesteding moet aantonen dat hij voldoet aan GO-ITS 25.12, en dit niet achteraf kan doen nadat het contract is getekend. De Compliance Advisory Services van Encryption Consulting zijn er precies voor dit hiaat: ze brengen de huidige cryptografische status van een leverancier in kaart aan de hand van Bijlage A van de standaard, nog voordat een offerte wordt ingediend.

Hoe kies je de juiste algoritmes en sleutellengtes?

Cryptografie beschermt de vertrouwelijkheid en integriteit van gevoelige informatie door middel van drie soorten algoritmen: symmetrische encryptie voor de vertrouwelijkheid van grote hoeveelheden gegevens, asymmetrische encryptie voor digitale handtekeningen en sleuteluitwisseling, en hashfuncties voor integriteitscontrole. Bijlage A van GO-ITS 25.12 stelt een minimale sleutellengte vast voor standaardgebruik en een langere voor risicovolle omgevingen. Elke keuze komt overeen met een onderliggende NIST-standaard, aangezien GO-ITS geen eigen cryptografische primitieven definieert.

Algoritmecategorie	Goedgekeurd algoritme	Minimale sleutellengte	Omgeving met hoog risico	Onderliggende NIST-standaard	Status
Symmetrische codering	AES	128-bit	256-bit	FIPS197	Goedgekeurd
Symmetrische encryptie (verouderd)	3DES (drievoudige DES)	168-bits nominaal, 112-bits effectief	Niet aangeraden	SP 800-131A Rev. 2	Verouderd, uitgefaseerd tegen 2030 volgens GO-ITS; NIST verbiedt nieuw gebruik al.
Symmetrische encryptie (stream)	ChaCha20-Poly1305	256-bit	256-bit	RFC 8439	Goedgekeurd
Asymmetrische encryptie en digitale handtekeningen	RSA	2048-bit	3072-bit	FIPS 186-5	Goedgekeurd
Asymmetrische handtekeningen (elliptische curve)	ECDSA	P-256	P-384	FIPS 186-5	Goedgekeurd
Asymmetrische signaturen (Edwards-curve)	EdDSA	Ed25519-equivalent	Ed448-equivalent	FIPS 186-5	Goedgekeurd
Hash-functies	SHA2-256-familie, SHA3-256-familie	256-bits uitvoer	256-bits uitvoer of sterker	FIPS 180-4, FIPS 202	Goedgekeurd
Hashfuncties (verouderd)	MD5, SHA-1	NB	NB	SP 800-131A Rev. 2	Niet toegestaan ​​voor digitale handtekeningen; alleen SHA-1 legacy-verificatie.
Berichtverificatie	HMAC (SHA2-256+), CMAC, GMAC, Poly1305	Komt overeen met het onderliggende algoritme	Komt overeen met het onderliggende algoritme	SP 800-38B, SP 800-38D, RFC 8439	Goedgekeurd

Tabel: GO-ITS 25.12 goedgekeurde algoritmen gekoppeld aan de bijbehorende NIST-standaarden.

De beveiligingsdrempel van 112 bits in NIST SP 800-131A Rev. 2 ligt ten grondslag aan de minimumvereisten van GO-ITS 25.12 voor RSA-2048 en ECC P-256: RSA vereist een modulus van 2048 bits en elliptische curve-schema's vereisen een groepsorde van ongeveer 224 bits of meer om diezelfde beveiligingsdrempel van 112 bits te bereiken. Voor een gedetailleerdere uitleg over hoe FIPS 140-3 deze algoritmen categoriseert op basis van hun goedkeuringsstatus, zie ons artikel over de overgang naar FIPS 140-3.

Tegen welke bedreigingen biedt GO-ITS 25.12 bescherming?

Elke eis in GO-ITS 25.12 is terug te voeren op een specifieke manier waarop gevoelige overheidsgegevens openbaar worden gemaakt. Inzicht in het dreigingsmodel maakt de eisen minder willekeurig en gemakkelijker te prioriteren, vooral wanneer de middelen beperkt zijn.

• Onderschepping tijdens transport. Ongecodeerd of zwak gecodeerd netwerkverkeer kan worden onderschept en gelezen door een aanvaller die zich op het netwerkpad bevindt. Daarom schrijft de standaard encryptie voor alle communicatie voor en verbiedt het gebruik van SSL en vroege TLS-versies die kwetsbaar zijn voor aanvallen waarbij het protocol wordt gedowngrade.
• Blootstelling van data in rusttoestand. Een gestolen laptop, een verkeerd geconfigureerde database of een gehackte opslagbucket legt direct onversleutelde gevoelige gegevens bloot, wat de noodzaak voor volledige schijfversleuteling en versleuteling op kolomniveau verklaart.
• Cryptanalyse van zwakke of verouderde primitieven. MD5 en SHA-1 zijn beide kwetsbaar voor botsingsaanvallen, en 3DES is gevoelig voor meet-in-the-middle- en birthday-bound-aanvallen bij grote hoeveelheden data. Daarom worden ze in de standaard afgekeurd ten gunste van SHA2/SHA3 en AES.
• Belangrijke inbreuken en misbruik door insiders. Een slecht beveiligde sleutel ondermijnt elke beveiligingsmaatregel die erop is gebouwd. Daarom beperkt GO-ITS 25.12 de toegang tot sleutels tot geautoriseerde gebruikers en diensten en vereist het gedocumenteerde procedures voor het genereren, distribueren, roteren en vernietigen ervan.
• Implementatiefouten. Het hergebruiken van een initialisatievector onder AES-GCM, of het gebruik van de Electronic Codebook (ECB)-modus, lekt structurele informatie over de platte tekst, zelfs wanneer het onderliggende algoritme correct is. GO-ITS 25.12 verbiedt de ECB-modus om deze reden expliciet.
• Oogst nu, decodeer later. Tegenstanders kunnen vandaag de dag versleuteld verkeer onderscheppen en decoderen zodra er een cryptografisch relevante kwantumcomputer bestaat. GO-ITS 25.12 schrijft nog geen post-kwantumalgoritmen voor, maar de tekst zelf benadrukt cryptografische flexibiliteit als verdediging tegen opkomende bedreigingen. Dit is dezelfde houding die NIST aanbeveelt in haar richtlijnen voor post-kwantummigratie. Zie onze handleiding voor deadlines voor de migratie naar post-kwantumcryptografie om te zien hoe andere rechtsgebieden deze overgang aanpakken.

Hoe voldoe je aan de GO-ITS 25.12-richtlijnen?

Naleving van GO-ITS 25.12 is een proces dat zich in een bepaalde volgorde voltrekt, niet iets wat je even afvinkt. Organisaties die dit als een eenmalige audit beschouwen, lopen het risico niet meer aan de voorschriften te voldoen zodra een algoritme verouderd raakt of een nieuw systeem wordt geïmplementeerd.

1. Inventariseer cryptografische activa. Identificeer elk algoritme, elke sleutel, elk certificaat en elk protocol dat in gebruik is, en classificeer de gevoeligheid van de gegevens die elk ervan beschermt. Zonder deze inventarisatie hebben de volgende stappen geen betrouwbaar uitgangspunt.
2. Vergelijk de huidige situatie met bijlage A. Vergelijk elk algoritme en elke sleutellengte in de inventaris met de GO-ITS 25.12-tabel met goedgekeurde algoritmen en markeer alles wat verboden, verouderd of onder de vereiste sleutellengte voor de betreffende risicocategorie is.
3. Verwijder verboden en verouderde primitieven. Verwijder DES, ECB-modus, MD5 voor handtekeningen, SHA-1 voor handtekeningen en SSL of vroege TLS waar deze nog voorkomen, met prioriteit voor systemen die met internet verbonden zijn.
4. Selecteer goedgekeurde algoritmen en sleutellengtes per risicocategorie. Voor data met een standaardrisico gelden de minimale sleutellengtes volgens de standaard; voor data met een hoog risico (of data die langer dan twee jaar wordt bewaard) gelden de minimale sleutellengtes voor data met een hoog risico uit de bovenstaande tabel.
5. Implementeer sleutelgeneratie en -opslag met HSM-ondersteuning. Voldoe minimaal aan FIPS 140-2 of FIPS 140-3 / ISO/IEC 19790:2012 niveau 2, en niveau 3 voor risicovolle informatie of implementatie buiten de eigen locatie. Generatie van zeer gevoelige sleutels moet binnen de eigen locatie plaatsvinden, indien de norm dit aanbeveelt.
6. Stel gedocumenteerde procedures op voor het beheer van de belangrijkste kernpunten. Dek het genereren, toewijzen, distribueren, roteren, intrekken en vernietigen van sleutels af en bewaar test- en productiesleutels in strikt gescheiden omgevingen.
7. Volledige beveiligingstests en -evaluatie (STE). Elke applicatie die gevoelige gegevens verwerkt of benadert, heeft STE nodig vóórdat deze in productie gaat, niet erna.
8. Zorg voor continue training, audits en monitoring. Technisch personeel moet permanent op de hoogte zijn van de vereisten, en HSM's en belangrijke beheersystemen moeten continu worden gemonitord, niet slechts eens per jaar worden geëvalueerd.

Wat zijn de afwegingen tussen prestaties en interoperabiliteit?

GO-ITS 25.12 keurt voor de meeste categorieën meer dan één algoritme goed, juist omdat geen enkele keuze op alle vlakken de beste is. Het kiezen van het juiste algoritme voor een bepaald systeem betekent dat prestaties, interoperabiliteit en de daadwerkelijk gebruikte hardware tegen elkaar moeten worden afgewogen.

Keuze	Relatieve prestaties	Interoperabiliteit	Beste pasvorm
AES-256-GCM versus AES-128-GCM	AES-256 voert meer rondes uit en is marginaal trager, hoewel dit verschil verwaarloosbaar is op hardware met AES-NI-acceleratie.	Universeel toepasbaar op moderne TLS-stacks en HSM's.	AES-256 voor risicovolle en langdurig bewaarde gegevens; AES-128 is elders acceptabel.
RSA-2048 versus ECDSA P-256	RSA ondertekent langzamer en verifieert sneller; ECDSA ondertekent sneller met een veel kleinere sleutel en handtekeninggrootte.	RSA heeft de breedste ondersteuning voor oudere clients; ECDSA vereist een redelijk moderne TLS-stack.	ECDSA voor nieuwe implementaties en clients met beperkte mogelijkheden; RSA waar interoperabiliteit met bestaande systemen een absolute vereiste is.
TLS 1.3 versus TLS 1.2	TLS 1.3 voltooit de handshake in één roundtrip (of nul, met hervatting), waardoor de latentie wordt verminderd.	TLS 1.2 wordt nog steeds breed ondersteund door oudere clients en middleware.	TLS 1.3 als standaard; houd TLS 1.2 alleen beschikbaar waar oudere clients dit vereisen.
HSM op locatie versus HSM buiten de locatie/in de cloud	Een on-premise oplossing vermijdt netwerkverkeer naar een externe HSM, maar brengt wel hogere opstartkosten met zich mee.	Cloud HSM schaalt sneller, maar moet voldoen aan FIPS 140-2/140-3 niveau 3 voor zeer gevoelige, externe toepassingen volgens GO-ITS 25.12.	On-premise voor de meest gevoelige sleutelgeneratie; cloud-HSM voor schaalbaarheid zodra validatie op niveau 3 is bevestigd.
ChaCha20-Poly1305 versus AES-GCM	ChaCha20 is sneller op apparaten zonder AES-NI hardwareversnelling; AES-GCM is sneller waar die versnelling wel aanwezig is.	Beide zijn standaard cipher suite-opties in TLS 1.2 en 1.3.	Stem de encryptiemethode af op het hardwareprofiel van het eindpunt: ChaCha20 voor mobiele apparaten en IoT, AES-GCM voor standaard serverhardware.

Tabel: Afwegingen tussen prestaties en interoperabiliteit bij de door GO-ITS 25.12 goedgekeurde opties.

Welke belangrijke beheerafhankelijkheden creëert GO-ITS 25.12?

Sleutelbeheer is waar de meeste GO-ITS 25.12-programma's daadwerkelijk slagen of falen, omdat de selectie van algoritmen een eenmalige beslissing is, terwijl sleutelbeheer een doorlopende operationele discipline is.

• De overheid is eigenaar van de sleutels. De overheid van Ontario behoudt het eigendom van de cryptografische sleutels die haar informatie beschermen, wat beperkingen oplegt aan de manier waarop beheerde diensten of cloudserviceproviders het beheer van deze sleutels kunnen vormgeven.
• HSM-afhankelijkheid. Voor het genereren en opslaan van zeer gevoelige sleutels is een HSM vereist die voldoet aan het FIPS 140-2/140-3-niveau dat overeenkomt met de risicocategorie van de gegevens. Dit betekent dat de aanschaf en het beheer van de levensduur van een HSM een compliance-afhankelijkheid wordt, en niet slechts een infrastructuurbeslissing.
• Herstelverplichtingen. Ontsleutelingssleutels moeten na het verlopen ervan herstelbaar blijven, zodat gearchiveerde back-ups leesbaar blijven. Dit vereist een gedocumenteerd sleutelbewarings- of herstelmechanisme, en niet alleen een rotatiebeleid.
• Scheiding van test- en productieprocessen. Sleutels die voor testdoeleinden zijn aangemaakt, mogen nooit in productieomgevingen voorkomen, en productiesleutels mogen nooit in testomgevingen voorkomen. Dit heeft concrete gevolgen voor de manier waarop CI/CD-pipelines en stagingomgevingen worden ingericht.
• Afhandeling van eigendomsoverdracht. Wanneer de verantwoordelijkheid voor gegevens naar een andere organisatie wordt overgedragen, moeten die gegevens opnieuw worden versleuteld met een nieuwe sleutel in plaats van dat de oude sleutel simpelweg wordt overgedragen. Dit heeft gevolgen voor elk migratie- of offboardingproject.
• Zichtbaarheid als voorwaarde. Geen van bovenstaande is mogelijk zonder eerst te weten welke sleutels, certificaten en algoritmen er in de omgeving aanwezig zijn. Daarom is een cryptografische inventarisatietool zoals deze onmisbaar. CBOM Secure is vaak de eerste praktische stap in een GO-ITS 25.12-programma, in plaats van iets wat achteraf wordt overwogen.

Hoe ziet een GO-ITS 25.12-compatibele implementatie eruit?

Bovenstaande eisen vertalen zich in concrete architectonische beslissingen. Enkele representatieve voorbeelden:

• Een webapplicatie die toegankelijk is voor het publiek. TLS 1.3 werd beëindigd bij de load balancer met behulp van een ECDSA P-256-certificaat, waarbij de privésleutel werd gegenereerd en bewaard in een HSM in plaats van op de schijf van de applicatieserver, en de cipher suites beperkt waren tot de algoritmen in de GO-ITS 25.12-tabel.
• Gevoelige databasevelden. Kolomversleuteling met AES-256-GCM voor velden met persoonlijke of gezondheidsinformatie, waarbij de versleutelingssleutels zijn ingekapseld in een door een HSM beveiligde hoofdsleutel in plaats van samen met de gegevens te worden opgeslagen.
• Overdracht van dossiers tussen ministeries. SSH 2.0 of nieuwer voor transport, AES-GCM of ChaCha20-Poly1305 voor de vertrouwelijkheid van de gegevens, en een HMAC-SHA2-256 of digitale handtekening voor integriteitsverificatie met een betrouwbaar tijdstempel.
• Codeondertekening en documentondertekening. RSA-3072- of ECDSA P-384-handtekeningen, ondersteund door een HSM-beveiligde ondertekeningssleutel, met een tijdstempel van een geldige, vertrouwde referentiebron, zodat de handtekening verifieerbaar blijft nadat het certificaat is verlopen.

Beperkingen

• GO-ITS 25.12 schrijft de post-kwantumalgoritmen van NIST (ML-KEM, ML-DSA, SLH-DSA) nog niet voor; het noemt cryptografische flexibiliteit als doelstelling zonder een specifiek tijdschema voor de migratie naar PQC te vereisen.
• De standaard benoemt goedgekeurde algoritmen en sleutellengtes, maar specificeert geen exacte TLS-coderingsreeksen, waardoor er ruimte is voor inconsistente implementatie tussen ministeries en leveranciers.
• Veel voorschriften gebruiken "zou moeten" in plaats van "moet", waardoor het eerder aanbevelingen dan bindende verplichtingen zijn, en de handhaving van "zou moeten"-formuleringen verschilt per ministerie.
• De standaard dateert van vóór de wijdverspreide cloud-native en efemere-sleutelarchitecturen en behandelt de specifieke controlemechanismen voor de cloud aan de gerelateerde GO-ITS 25.21-standaard voor cloudservices in plaats van ze direct te omvatten.
• GO-ITS 25.12 schrijft zelf geen specifieke eisen voor crypto-agility-tools of -inventarisatie voor, hoewel crypto-agility wel wordt genoemd als verdediging tegen opkomende bedreigingen.

Wat zou Encryption Consulting aanbevelen?

De meeste organisaties waarmee we samenwerken aan GO-ITS 25.12 falen niet op het gebied van algoritmeselectie. De tabel in Appendix A is niet moeilijk te lezen. Ze falen echter op het operationele vlak daaronder: niemand heeft een actuele inventaris van welke algoritmen en sleutels er daadwerkelijk bestaan, de aanschaf van HSM's duurt maanden en de procedures voor sleutelbeheer zitten in iemands hoofd in plaats van in een document dat een auditor kan inzien.

Ons advies is om het probleem in deze volgorde aan te pakken. Begin met een gap-analyse via Compliance Advisory Services , waarbij de huidige algoritmen, sleutellengtes en protocollen direct worden vergeleken met de tabel in Bijlage A van GO-ITS 25.12. Dit resulteert in een geprioriteerd herstelplan in plaats van een algemeen auditrapport. Als de lacune betrekking heeft op het validatieniveau van de HSM, zorgt HSM-as-a-Service ervoor dat een organisatie FIPS 140-2/140-3 niveau 2 of niveau 3 gevalideerde sleutelbescherming kan bereiken zonder een maandenlange hardware-aankoopcyclus, wat van belang is wanneer er een deadline voor een aanbesteding is. Als de lacune betrekking heeft op de uitgifte, intrekking of afstemming van CP/CPS op certificaten, bouwt ons PKI Services- team het beleids- en technische raamwerk op dat ervoor zorgt dat certificaatpraktijken controleerbaar zijn aan de hand van de standaard, in plaats van dat ze per project worden geïmproviseerd.

We willen ons ook voorzichtig verzetten tegen het idee om 2030 als een comfortabele deadline te beschouwen voor het uitfaseren van 3DES. De eigen transitierichtlijnen van NIST verbieden al nieuwe 3DES-encryptie, en het specificeren van AES vanaf dag één op elk nieuw systeem van de overheid van Ontario kost niets extra en elimineert een toekomstige noodzaak tot herstel volledig.

Conclusie

GO-ITS 25.12 is bedoeld om de vertrouwelijkheid en integriteit van gevoelige informatie binnen de openbare dienst van Ontario te beschermen. Dit wordt bereikt door alle ministeries en leveranciers te verwijzen naar dezelfde goedgekeurde algoritmen, sleutellengtes en HSM-validatieniveaus, in plaats van cryptografische keuzes over te laten aan individuele projectteams. De technische vereisten zijn niet het moeilijkste. Het opbouwen van de inventaris, de discipline voor sleutelbeheer en de HSM-infrastructuur die ervoor zorgen dat aan deze vereisten continu wordt voldaan, is waar organisaties daadwerkelijk hulp bij nodig hebben. Een gestructureerd complianceprogramma betaalt zichzelf ruimschoots terug, nog voordat er een audit plaatsvindt.

Veelgestelde Vragen / FAQ

Wat is GO-ITS 25.12? GO-ITS 25.12 is de IT-standaard van de overheid van Ontario met de titel "Beveiligingsvereisten voor het gebruik van cryptografie". Deze standaard beschrijft de goedgekeurde cryptografische algoritmen, minimale sleutellengtes en protocollen die ministeries, agentschappen en hun leveranciers binnen de openbare dienst van Ontario moeten gebruiken om gevoelige overheidsinformatie te beschermen tijdens opslag en transport.

Wie moet voldoen aan GO-ITS 25.12? De norm is van toepassing op ministeries van de overheid van Ontario, voormalige agentschappen van Bijlage I en IV, cloudserviceproviders en elke derde partij of leverancier met een contract met de overheid van Ontario die informatie van de openbare dienst van Ontario creëert, opslaat, verzendt of verwerkt.

Welk validatieniveau voor HSM's vereist GO-ITS 25.12? Hardwarebeveiligingsmodules die sleutels van de overheid van Ontario beschermen, moeten minimaal gevalideerd zijn volgens FIPS 140-2 of FIPS 140-3 / ISO/IEC 19790:2012 niveau 2. HSM's die zeer gevoelige informatie buiten de locatie opslaan, moeten voldoen aan niveau 3.

Vereist GO-ITS 25.12 TLS 1.3? GO-ITS 25.12 vereist ondersteuning voor TLS en schrijft specifiek TLS 1.2 en 1.3 voor, terwijl SSL en vroege, kwetsbare versies van TLS worden verboden. Cipher suites moeten worden gekozen uit de goedgekeurde algoritme- en sleutellengtetabel van de standaard.

Is 3DES nog steeds toegestaan ​​onder GO-ITS 25.12? De algoritmetabel van GO-ITS 25.12 vermeldt 3DES nog steeds, met richtlijnen van de overheid van Ontario die gericht zijn op de uitfasering ervan in 2030. De eigen transitierichtlijnen van NIST verbieden 3DES-encryptie al voor nieuw gebruik, dus Encryption Consulting adviseert om AES in plaats van 3DES te specificeren voor elke nieuwe implementatie door de overheid van Ontario.

Referenties

• Overheid van Ontario: GO-ITS 25.12, Beveiligingsvereisten voor het gebruik van cryptografie
• Overheid van Ontario: Programma voor normen inzake informatietechnologie
• NIST FIPS 140-3, Beveiligingseisen voor cryptografische modules
• NIST FIPS 197, Advanced Encryption Standard (AES)
• NIST FIPS 186-5, Digitale handtekeningstandaard (DSS)
• NIST SP 800-131A Rev. 2, Overgang van het gebruik van cryptografische algoritmen en sleutellengtes
• NIST CSRC: FIPS 140-3 overgangsinspanning