Schützen Sie die Vertraulichkeit und Integrität sensibler Informationen mit GO-ITS 25.12

Das Programm „Informationstechnologiestandards der Regierung von Ontario“ (GO-ITS) legt die Richtlinien, Standards und Verfahren fest, die die Ministerien des öffentlichen Dienstes von Ontario und ihre Dienstleister einhalten müssen. GO-ITS 25.12, „ Sicherheitsanforderungen für die Verwendung von Kryptografie“ , ist der Standard, der allen Ministerien, Behörden und Drittanbietern, die mit Daten der Regierung von Ontario arbeiten, genau vorgibt, welche kryptografischen Algorithmen, Schlüssellängen und Protokolle zum Schutz der Vertraulichkeit und Integrität sensibler Informationen zugelassen sind.

In der Norm sind mit „muss“ gekennzeichnete Anforderungen verbindlich, mit „ sollte“ gekennzeichnete Anforderungen hingegen Empfehlungen. GO-ITS 25.12 gilt für Ministerien der Regierung von Ontario, ehemalige Behörden der Kategorien I und IV, Cloud-Dienstleister sowie alle Lieferanten oder Drittanbieter, die im Auftrag der Regierung von Ontario Informationen des öffentlichen Dienstes von Ontario erstellen, speichern, übermitteln oder verarbeiten.

Veröffentlicht: März 2022. Aktualisiert: August 2026. Geprüft vom Compliance Advisory Team von Encryption Consulting.

Was benötigt GO-ITS 25.12?

GO-ITS 25.12 schreibt vor, dass sensible Informationen der Regierung von Ontario in jeder Phase – Erstellung, Speicherung, Verteilung, Nutzung, Widerruf, Vernichtung und Wiederherstellung der zugehörigen Schlüssel – mithilfe zugelassener kryptografischer Algorithmen geschützt werden müssen. Die Anforderungen sind in klar abgegrenzte Bereiche unterteilt, und jeder Bereich entspricht einer konkreten operativen Kontrollmaßnahme und nicht nur einem vagen Prinzip.

• Schul-und Berufsbildung. Technisches Personal, das Systeme entwickelt, implementiert oder verwaltet, die Kryptographie verwenden, muss die Anforderungen des Standards verstehen, bevor es mit Produktionssystemen arbeitet.
• Informationen im Speicher. Sensible Daten müssen im Ruhezustand verschlüsselt werden. Daten, die länger als zwei Jahre gespeichert werden, müssen mit einer für Hochrisikoumgebungen geeigneten Verschlüsselung verschlüsselt werden. Mobile Geräte müssen eine vollständige Festplattenverschlüsselung verwenden, und sensible Felder müssen auf Spalten- oder Zellenebene verschlüsselt werden, bevor sie in ein Datenrepository gelangen.
• Kommunikationssicherheit. Sensible Informationen müssen während der Übertragung verschlüsselt werden, und ihre Integrität muss mit einem genehmigten Message Authentication Code oder einer digitalen Signatur mit einem genauen, vertrauenswürdigen Zeitstempel überprüft werden.
• Kryptografie-Implementierung. Anwendungen müssen einen zugelassenen Zufalls- oder Pseudozufallszahlengenerator verwenden, Zertifikate vor der Vertrauenswürdigkeit validieren, entschlüsselte Daten unmittelbar nach der Verwendung aus dem Cache oder temporären Speicher löschen und Sicherheitstests und -bewertungen (STE) bestehen, bevor sie live gehen.
• Schutz kryptographischen Materials. Der Zugriff auf die Schlüssel ist auf autorisierte Benutzer und Dienste beschränkt, der Schlüsselschutz skaliert mit der Datensensibilität, und die Schlüsselgenerierung sollte auf einem zugelassenen Softwaremodul oder einem Hardware-Sicherheitsmodul (HSM) vor Ort erfolgen, wo immer die Informationen hochsensibel sind.

Wer muss GO-ITS 25.12 einhalten?

GO-ITS 25.12 gilt für einen größeren Kreis als nur die Ministerien, die die Verträge ausstellen. Jeder, der im Rahmen eines Vertrags mit Daten des öffentlichen Dienstes von Ontario in Berührung kommt, unterliegt den Verpflichtungen dieses Standards.

• Ministerien der Regierung von Ontario und ehemalige Behörden der Kategorien I und IV.
• Drittanbieter und Systemintegratoren, die im Auftrag der Regierung von Ontario tätig sind.
• Cloud-Service-Anbieter, die Workloads oder Daten des öffentlichen Dienstes von Ontario hosten.
• Jede Organisation, die Informationen der Regierung von Ontario erstellt, speichert, übermittelt oder verarbeitet, unabhängig davon, wo diese Verarbeitung physisch stattfindet.

In der Praxis bedeutet dies, dass ein Anbieter, der sich um einen Auftrag der Regierung von Ontario bewirbt, die Konformität mit GO-ITS 25.12 bereits während des Vergabeverfahrens nachweisen muss und diese nicht erst nach Vertragsunterzeichnung nachträglich einführen darf. Die Compliance-Beratungsdienste von Encryption Consulting schließen genau diese Lücke: Sie gleichen den aktuellen kryptografischen Status eines Anbieters mit Anhang A des Standards ab, bevor ein Angebot abgegeben wird.

Wie wählt man die richtigen Algorithmen und Schlüssellängen aus?

Kryptografie schützt die Vertraulichkeit und Integrität sensibler Informationen durch drei Algorithmenfamilien: symmetrische Verschlüsselung für die Massenvertraulichkeit, asymmetrische Verschlüsselung für digitale Signaturen und Schlüsselaustausch sowie Hash-Funktionen zur Integritätsprüfung. Anhang A von GO-ITS 25.12 legt eine minimale Schlüssellänge für den Standardgebrauch und eine höhere für Hochrisikoumgebungen fest. Jede dieser Optionen entspricht einem zugrunde liegenden NIST-Standard, da GO-ITS keine eigenen kryptografischen Primitiven definiert.

Algorithmenkategorie	Genehmigter Algorithmus	Minimale Tastenlänge	Hochrisikoumgebung	Zugrunde liegender NIST-Standard	Status
Symmetrische Verschlüsselung	AES	128-bit	256-bit	FIPS197	Genehmigt
Symmetrische Verschlüsselung (älteres System)	3DES (Triple DES)	168 Bit nominal, 112 Bit effektiv	Nicht empfehlenswert	SP 800-131A Rev. 2	Veraltet, Auslaufen bis 2030 gemäß GO-ITS; NIST untersagt bereits die neue Verwendung
Symmetrische Verschlüsselung (Stream)	ChaCha20-Poly1305	256-bit	256-bit	RFC 8439	Genehmigt
Asymmetrische Verschlüsselung und Signaturen	RSA	2048-bit	3072-bit	FIPS 186-5	Genehmigt
Asymmetrische Signaturen (elliptische Kurve)	ECDSA	P-256	P-384	FIPS 186-5	Genehmigt
Asymmetrische Signaturen (Randkurve)	EdDSA	Ed25519-Äquivalent	Ed448-Äquivalent	FIPS 186-5	Genehmigt
Hash-Funktionen	SHA2-256-Familie, SHA3-256-Familie	256-Bit-Ausgabe	256-Bit-Ausgabe oder höher	FIPS 180-4, FIPS 202	Genehmigt
Hashfunktionen (veraltet)	MD5, SHA-1	N / A	N / A	SP 800-131A Rev. 2	Für digitale Signaturen verboten; nur SHA-1-Legacy-Verifizierung
Nachrichtenauthentifizierung	HMAC (SHA2-256+), CMAC, GMAC, Poly1305	Entspricht dem zugrunde liegenden Algorithmus	Entspricht dem zugrunde liegenden Algorithmus	SP 800-38B, SP 800-38D, RFC 8439	Genehmigt

Tabelle: Von GO-ITS 25.12 genehmigte Algorithmen den entsprechenden NIST-Standards zugeordnet.

Die in NIST SP 800-131A Rev. 2 festgelegte Sicherheitsstärke von 112 Bit bildet die Grundlage für die Mindestanforderungen von GO-ITS 25.12 für RSA-2048 und ECC P-256: RSA benötigt einen 2048-Bit-Modulus, und elliptische Kurvenverfahren benötigen eine Gruppenordnung von mindestens 224 Bit, um diese Mindeststärke von 112 Bit zu erreichen. Weitere Informationen zur Kategorisierung dieser Algorithmen nach Zulassungsstatus gemäß FIPS 140-3 finden Sie in unserem Beitrag zum Übergang zu FIPS 140-3.

Gegen welche Bedrohungen schützt GO-ITS 25.12?

Jede Anforderung in GO-ITS 25.12 lässt sich auf eine konkrete Methode zurückführen, mit der sensible Regierungsdaten offengelegt werden. Das Verständnis des Bedrohungsmodells lässt die Anforderungen weniger willkürlich erscheinen und erleichtert die Priorisierung bei begrenzten Ressourcen.

• Abfangen während des Transports. Unverschlüsselter oder schwach verschlüsselter Netzwerkverkehr kann von einem Angreifer, der sich auf dem Netzwerkpfad befindet, abgefangen und gelesen werden. Deshalb schreibt der Standard die Verschlüsselung für die gesamte Kommunikation vor und verbietet SSL und frühe TLS-Versionen, die anfällig für Protokoll-Downgrade-Angriffe sind.
• Offenlegung ruhender Daten. Ein gestohlener Laptop, eine falsch konfigurierte Datenbank oder ein kompromittierter Speicherbereich legen unverschlüsselte sensible Daten direkt offen, was die Anforderungen an eine vollständige Festplattenverschlüsselung und eine spaltenweise Verschlüsselung begründet.
• Kryptoanalyse schwacher oder veralteter Primitiven. Sowohl MD5 als auch SHA-1 weisen praktische Kollisionsangriffe auf, und 3DES ist bei großen Datenmengen anfällig für Meet-in-the-Middle- und Birthday-Bound-Angriffe. Aus diesem Grund werden sie im Standard zugunsten von SHA2/SHA3 und AES als veraltet eingestuft.
• Schlüsselkompromittierung und Missbrauch durch Insider. Ein schlecht geschützter Schlüssel untergräbt alle darauf aufbauenden Kontrollmechanismen. Aus diesem Grund beschränkt GO-ITS 25.12 den Schlüsselzugriff auf autorisierte Benutzer und Dienste und schreibt dokumentierte Verfahren für Generierung, Verteilung, Rotation und Vernichtung vor.
• Implementierungsmängel. Die Wiederverwendung eines Initialisierungsvektors unter AES-GCM oder die Verwendung des Electronic Codebook (ECB)-Modus gibt Strukturinformationen über den Klartext preis, selbst wenn der zugrunde liegende Algorithmus korrekt ist. GO-ITS 25.12 verbietet den ECB-Modus aus diesem Grund ausdrücklich.
• Jetzt ernten, später entschlüsseln. Angreifer können bereits heute verschlüsselten Datenverkehr abfangen und ihn entschlüsseln, sobald ein kryptografisch geeigneter Quantencomputer existiert. GO-ITS 25.12 schreibt zwar noch keine Post-Quanten-Algorithmen vor, hebt aber in seinem Text kryptografische Flexibilität als Verteidigung gegen neue Bedrohungen hervor – dieselbe Vorgehensweise, die das NIST in seinen Leitlinien zur Post-Quanten-Migration empfiehlt. Siehe unseren Leitfaden zu Fristen für die Migration zur Post-Quanten-Kryptographie wie andere Rechtsordnungen diesen Übergang handhaben.

Wie erreichen Sie die Einhaltung von GO-ITS 25.12?

Die Einhaltung von GO-ITS 25.12 ist ein fortlaufender Prozess, keine einmalige Prüfung. Organisationen, die GO-ITS 25.12 als einmalige Maßnahme betrachten, laufen Gefahr, die Vorgaben nicht mehr zu erfüllen, sobald ein Algorithmus veraltet ist oder ein neues System eingeführt wird.

1. Inventarisierung kryptografischer Vermögenswerte. Identifizieren Sie alle verwendeten Algorithmen, Schlüssel, Zertifikate und Protokolle und klassifizieren Sie die Sensibilität der jeweils geschützten Daten. Ohne diese Bestandsaufnahme haben die folgenden Schritte keine verlässliche Grundlage.
2. Vergleichen Sie den aktuellen Zustand mit Anhang A. Vergleichen Sie jeden Algorithmus und jede Schlüssellänge im Inventar mit der Tabelle der gemäß GO-ITS 25.12 zugelassenen Algorithmen und kennzeichnen Sie alle verbotenen, veralteten oder unterhalb der für die jeweilige Risikostufe erforderlichen Schlüssellänge liegenden Algorithmen.
3. Verbotene und veraltete primitive Funktionen aus dem Verkehr ziehen. Entfernen Sie DES, ECB-Modus, MD5 für Signaturen, SHA-1 für Signaturen und SSL oder frühe TLS-Versionen, wo immer sie noch vorkommen, wobei Sie Systeme mit Internetanbindung priorisieren.
4. Wählen Sie pro Risikostufe zugelassene Algorithmen und Schlüssellängen aus. Für Daten mit Standardrisiko gelten die Mindestschlüssellängen des Standards; für Daten mit hohem Risiko (oder alles, was länger als zwei Jahre aufbewahrt wird) gelten die Mindestwerte für hohes Risiko aus der obigen Tabelle.
5. Bereitstellung von HSM-gestützter Schlüsselgenerierung und -speicherung. Mindestens die Anforderungen von FIPS 140-2 oder FIPS 140-3 / ISO/IEC 19790:2012 Level 2 erfüllen, und Level 3 für Informationen mit hohem Risiko oder für den Einsatz außerhalb des Firmengeländes, wobei die Generierung hochsensibler Schlüssel vor Ort erfolgen sollte, sofern dies im Standard empfohlen wird.
6. Erstellen Sie dokumentierte Schlüsselverwaltungsverfahren. Die Generierung, Zuweisung, Verteilung, Rotation, der Widerruf und die Vernichtung von Schlüsseln müssen abgedeckt sein. Test- und Produktionsschlüssel müssen in strikt getrennten Umgebungen aufbewahrt werden.
7. Vollständige Sicherheitsprüfung und -bewertung (STE). Jede Anwendung, die sensible Daten verarbeitet oder darauf zugreift, benötigt STE, bevor sie in Produktion geht, nicht erst danach.
8. Kontinuierliche Schulungen, Audits und Kontrollen einführen. Das technische Personal muss sich der Anforderungen stets bewusst sein, und HSMs und Schlüsselverwaltungssysteme benötigen eine kontinuierliche Überwachung, nicht nur eine jährliche Überprüfung.

Welche Kompromisse gibt es hinsichtlich Leistung und Interoperabilität?

GO-ITS 25.12 genehmigt für die meisten Kategorien mehr als einen Algorithmus, da kein einzelner Algorithmus in allen Dimensionen optimal ist. Die Auswahl des richtigen Algorithmus für ein bestimmtes System erfordert eine Abwägung von Leistung, Interoperabilität und der tatsächlich eingesetzten Hardware.

choice	Relative Leistung	Flexibel Kommunikation	Beste Passform
AES-256-GCM vs. AES-128-GCM	AES-256 führt mehr Runden aus und ist geringfügig langsamer, wobei der Unterschied auf Hardware mit AES-NI-Beschleunigung vernachlässigbar ist.	Universell einsetzbar in allen modernen TLS-Stacks und HSMs	AES-256 für risikoreiche und langzeitaufbewahrende Daten; AES-128 ist andernorts akzeptabel.
RSA-2048 vs. ECDSA P-256	RSA signiert langsamer und verifiziert schneller; ECDSA signiert schneller mit einem deutlich kleineren Schlüssel und einer kleineren Signaturgröße.	RSA bietet die breiteste Unterstützung für ältere Clients; ECDSA benötigt einen relativ modernen TLS-Stack.	ECDSA für neue Implementierungen und eingeschränkte Clients; RSA, wenn die Interoperabilität mit älteren Systemen eine zwingende Voraussetzung ist.
TLS 1.3 vs. TLS 1.2	TLS 1.3 schließt den Handshake in einem Roundtrip ab (oder in keinem, mit Wiederaufnahme), wodurch die Latenz reduziert wird.	TLS 1.2 genießt nach wie vor eine breitere Unterstützung bei älteren Clients und Middleboxes.	TLS 1.3 als Standard; TLS 1.2 nur noch dort verfügbar halten, wo ältere Clients es benötigen.
Lokales HSM vs. externes/Cloud-HSM	Die On-Premises-Lösung vermeidet Netzwerk-Roundtrips zu einem entfernten HSM, verursacht jedoch höhere Vorabkosten.	Cloud-HSM skaliert schneller, muss aber gemäß GO-ITS 25.12 die Anforderungen von FIPS 140-2/140-3 Level 3 für hochsensible, externe Anwendungen erfüllen.	Lokale Lösung für die Generierung hochsensibler Schlüssel; Cloud-HSM für Skalierbarkeit nach Bestätigung der Level-3-Validierung.
ChaCha20-Poly1305 vs. AES-GCM	ChaCha20 ist schneller auf Geräten ohne AES-NI-Hardwarebeschleunigung; AES-GCM ist schneller, wenn diese Beschleunigung vorhanden ist.	Beide sind Standard-Verschlüsselungssuite-Optionen in TLS 1.2 und 1.3.	Wählen Sie den Verschlüsselungsalgorithmus passend zum Hardwareprofil des Endpunkts: ChaCha20 für Mobilgeräte und IoT, AES-GCM für Standard-Serverhardware.

Tabelle: Kompromisse zwischen Leistung und Interoperabilität bei den von GO-ITS 25.12 zugelassenen Optionen.

Welche Schlüsselverwaltungsabhängigkeiten erzeugt GO-ITS 25.12?

Das Schlüsselmanagement ist der Punkt, an dem die meisten GO-ITS 25.12-Programme tatsächlich Erfolg oder Misserfolg haben, denn die Algorithmusauswahl ist eine einmalige Entscheidung, während das Schlüsselmanagement eine fortlaufende operative Disziplin darstellt.

• Die Schlüssel befinden sich im Besitz der Regierung. Die Regierung von Ontario behält das Eigentum an den kryptografischen Schlüsseln zum Schutz ihrer Informationen, was die Gestaltung der Schlüsselverwaltung durch Managed Services oder Cloud Service Provider einschränkt.
• HSM-Abhängigkeit. Für die Generierung und Speicherung hochsensibler Schlüssel ist ein HSM erforderlich, das dem FIPS 140-2/140-3-Niveau entsprechend der Risikostufe der Daten entspricht. Dies bedeutet, dass die Beschaffung und das Lebenszyklusmanagement des HSM zu einer Compliance-Abhängigkeit und nicht nur zu einer Infrastrukturentscheidung werden.
• Rückforderungsverpflichtungen. Die Entschlüsselungsschlüssel müssen auch nach Ablauf ihrer Gültigkeit wiederherstellbar bleiben, damit archivierte Backups lesbar bleiben. Dies erfordert einen dokumentierten Schlüssel-Hinterlegungs- oder Wiederherstellungsmechanismus und nicht nur eine Rotationsrichtlinie.
• Trennung von Test- und Produktionsbetrieb. Für Testzwecke erstellte Schlüssel dürfen niemals in der Produktion verwendet werden, und Produktionsschlüssel dürfen niemals in Testumgebungen verwendet werden. Dies hat konkrete Auswirkungen auf die Bereitstellung von CI/CD-Pipelines und Staging-Umgebungen.
• Abwicklung von Eigentumsübertragungen. Wenn die Datenverantwortung an eine andere Organisation übertragen wird, müssen diese Daten mit einem neuen Schlüssel neu verschlüsselt werden, anstatt dass einfach der alte Schlüssel den Besitzer wechselt. Dies wirkt sich auf jedes Migrations- oder Offboarding-Projekt aus.
• Sichtbarkeit als Voraussetzung. Nichts davon ist erreichbar, ohne vorher zu wissen, welche Schlüssel, Zertifikate und Algorithmen in der Umgebung vorhanden sind. Deshalb ist ein kryptografisches Inventarisierungstool wie CBOM Secure ist oft der erste praktische Schritt in einem GO-ITS 25.12-Programm und nicht eine nachträgliche Überlegung.

Wie sieht eine GO-ITS 25.12-konforme Implementierung aus?

Die oben genannten Anforderungen lassen sich in konkrete architektonische Entscheidungen umsetzen. Einige repräsentative Beispiele:

• Öffentlich zugängliche Webanwendung. TLS 1.3 wird am Load Balancer mit einem ECDSA P-256-Zertifikat terminiert, wobei der private Schlüssel in einem HSM und nicht auf der Festplatte des Anwendungsservers generiert und gespeichert wird und die Cipher Suites auf die Algorithmen in der GO-ITS 25.12-Tabelle beschränkt sind.
• Sensible Datenbankfelder. Spaltenbasierte Verschlüsselung mit AES-256-GCM für Felder, die persönliche oder Gesundheitsdaten enthalten, wobei die Datenverschlüsselungsschlüssel durch einen HSM-geschützten Hauptschlüssel geschützt und nicht zusammen mit den Daten gespeichert werden.
• Ministerieller Datenaustausch. Für den Transport wird SSH 2.0 oder neuer verwendet, für die Vertraulichkeit der Nutzdaten AES-GCM oder ChaCha20-Poly1305 und für die Integritätsprüfung eine HMAC-SHA2-256- oder digitale Signatur mit einem vertrauenswürdigen Zeitstempel.
• Codesignierung und Dokumentensignierung. RSA-3072- oder ECDSA P-384-Signaturen, die durch einen HSM-geschützten Signaturschlüssel abgesichert sind, mit einem Zeitstempel aus einer gültigen, vertrauenswürdigen Referenzquelle, sodass die Signatur auch nach Ablauf des Zertifikats überprüfbar bleibt.

Einschränkungen

• GO-ITS 25.12 schreibt die Post-Quanten-Algorithmen des NIST (ML-KEM, ML-DSA, SLH-DSA) noch nicht vor; es nennt kryptografische Agilität als Ziel, ohne einen spezifischen Zeitplan für die Migration zu PQC zu fordern.
• Der Standard benennt zwar zugelassene Algorithmen und Schlüssellängen, legt aber keine genauen TLS-Verschlüsselungssuiten fest, was Raum für uneinheitliche Implementierungen zwischen verschiedenen Ministerien und Anbietern lässt.
• Viele Anforderungen verwenden „sollte“ statt „muss“, wodurch sie eher Empfehlungen als verbindliche Verpflichtungen darstellen, und die Durchsetzung der „sollte“-Formulierung variiert je nach Ministerium.
• Der Standard entstand vor der Einführung weit verbreiteter Cloud-nativer und ephemerer Schlüsselarchitekturen und überlässt die Cloud-spezifischen Kontrollen dem verwandten Cloud-Services-Standard GO-ITS 25.21, anstatt sie direkt abzudecken.
• GO-ITS 25.12 schreibt selbst keine spezifischen Anforderungen an Werkzeuge oder Inventar für Krypto-Agilität vor, obwohl es Krypto-Agilität als Verteidigung gegen neu auftretende Bedrohungen nennt.

Was würde Encryption Consulting empfehlen?

Die meisten Organisationen, mit denen wir im Rahmen von GO-ITS 25.12 zusammenarbeiten, scheitern nicht an der Algorithmenauswahl. Die Tabelle in Anhang A ist leicht verständlich. Ihr Problem liegt in der operativen Umsetzung: Niemand verfügt über eine aktuelle Übersicht der tatsächlich vorhandenen Algorithmen und Schlüssel, die HSM-Beschaffung dauert Monate, und die Verfahren zur Schlüsselverwaltung existieren nur im Kopf einer Person, anstatt in einem Dokument festgehalten zu sein, das ein Auditor überprüfen kann.

Wir empfehlen, das Problem in dieser Reihenfolge anzugehen. Beginnen Sie mit einer Gap-Analyse durch unsere Compliance Advisory Services . Diese vergleicht die aktuellen Algorithmen, Schlüssellängen und Protokolle direkt mit der Tabelle in Anhang A von GO-ITS 25.12 und erstellt so einen priorisierten Maßnahmenplan anstelle eines allgemeinen Prüfberichts. Betrifft die Lücke die HSM-Validierungsstufe, ermöglicht HSM-as-a-Service Ihrem Unternehmen den Zugang zu FIPS 140-2/140-3 Level 2 oder Level 3 validiertem Schlüsselschutz – ohne mehrmonatigen Hardware-Beschaffungszyklus. Dies ist besonders wichtig bei festen Angebotsfristen. Betrifft die Lücke die Zertifikatsausstellung, den Zertifikatswiderruf oder die CP/CPS-Anpassung, entwickelt unser PKI-Services- Team die Richtlinien und den technischen Rahmen, der die Zertifizierungspraxis standardkonform auditierbar macht und nicht projektbezogen improvisiert.

Wir würden uns auch dagegen aussprechen, das Jahr 2030 als komfortablen Stichtag für die Abschaffung von 3DES zu betrachten. Die Übergangsrichtlinien des NIST schließen neue 3DES-Verschlüsselungen bereits aus, und die Vorgabe von AES von Anfang an für jedes neue System der Regierung von Ontario verursacht keine zusätzlichen Kosten und beseitigt einen zukünftigen Nachbesserungsbedarf vollständig.

Fazit

GO-ITS 25.12 dient dem Schutz der Vertraulichkeit und Integrität sensibler Informationen im gesamten öffentlichen Dienst von Ontario. Dies wird erreicht, indem alle Ministerien und Anbieter auf dieselbe Tabelle mit genehmigten Algorithmen, Schlüssellängen und HSM-Validierungsstufen verweisen, anstatt die kryptografischen Entscheidungen den einzelnen Projektteams zu überlassen. Die technischen Anforderungen sind nicht die größte Herausforderung. Der Aufbau des Inventars, die Disziplin im Schlüsselmanagement und die HSM-Infrastruktur, die diese Anforderungen dauerhaft erfüllen, sind die Bereiche, in denen Organisationen tatsächlich Unterstützung benötigen. Hier amortisiert sich ein strukturiertes Compliance-Programm bereits lange vor einer Prüfung.

Häufig gestellte Fragen

Was ist GO-ITS 25.12? GO-ITS 25.12 ist der IT-Standard der Regierung von Ontario mit dem Titel „Sicherheitsanforderungen für die Verwendung von Kryptografie“. Er legt die zugelassenen kryptografischen Algorithmen, Mindestschlüssellängen und Protokolle fest, die Ministerien, Behörden und deren Dienstleister des öffentlichen Dienstes von Ontario zum Schutz sensibler Regierungsdaten bei der Speicherung und Übertragung verwenden müssen.

Wer muss GO-ITS 25.12 einhalten? Der Standard gilt für Ministerien der Regierung von Ontario, ehemalige Behörden der Kategorien I und IV, Cloud-Service-Anbieter sowie alle Drittanbieter oder Lieferanten, die im Auftrag der Regierung von Ontario Informationen des öffentlichen Dienstes von Ontario erstellen, speichern, übermitteln oder verarbeiten.

Welche HSM-Validierungsstufe fordert GO-ITS 25.12? Hardware-Sicherheitsmodule (HSMs), die Schlüssel der Regierung von Ontario schützen, müssen mindestens nach FIPS 140-2 oder FIPS 140-3 / ISO/IEC 19790:2012 Level 2 validiert sein. HSMs, die hochsensible Informationen außerhalb des Firmengeländes speichern, sollten Level 3 erfüllen.

Benötigt GO-ITS 25.12 TLS 1.3? GO-ITS 25.12 erfordert die Unterstützung von TLS und fordert ausdrücklich TLS 1.2 und 1.3, während SSL und ältere, anfällige TLS-Versionen nicht zulässig sind. Die Verschlüsselungssammlungen müssen aus der im Standard festgelegten Tabelle mit den zugelassenen Algorithmen und Schlüssellängen ausgewählt werden.

Ist 3DES gemäß GO-ITS 25.12 noch zulässig? Die Algorithmentabelle von GO-ITS 25.12 führt 3DES weiterhin auf, obwohl die Regierung von Ontario die Abschaffung bis 2030 anstrebt. Die Übergangsrichtlinien des NIST untersagen bereits die Verwendung von 3DES-Verschlüsselung für neue Anwendungen. Daher empfiehlt Encryption Consulting, für alle neuen Implementierungen der Regierung von Ontario AES anstelle von 3DES zu spezifizieren.

Referenzen

• Regierung von Ontario: GO-ITS 25.12, Sicherheitsanforderungen für die Verwendung von Kryptographie
• Regierung von Ontario: Programm für Informationstechnologiestandards
• NIST FIPS 140-3, Sicherheitsanforderungen für kryptografische Module
• NIST FIPS 197, Advanced Encryption Standard (AES)
• NIST FIPS 186-5, Standard für digitale Signaturen (DSS)
• NIST SP 800-131A Rev. 2, Übergang bei der Verwendung kryptografischer Algorithmen und Schlüssellängen
• NIST CSRC: FIPS 140-3 Übergangsbemühungen