Importsubstitution von Betriebssystemen. Wie sehe ich ein inländisches Betriebssystem?

Wenn wir über die Verteilung des Betriebssystems sprechen, dann geht es in der ersten Runde nicht um den Kernel des Betriebssystems, sondern um die Anwendungen, die Teil der Verteilung sind. Und wenn wir über die Importsubstitution von Betriebssystemen sprechen, sprechen wir über eine bestimmte Linux-Version. Auf dem russischen Markt wird nichts anderes zur Importsubstitution angeboten. Für den Linux-Kernel ist Linus Benedict Torvalds für dessen Entwicklung verantwortlich. Und um ehrlich zu sein, weiß ich nichts über den russischen Linux-Kernel. Die Umgebung einer Linux-Distribution wird jedoch von verschiedenen Organisationen entwickelt, die nicht alle aufgelistet werden können: KDE, Mozilla, Google, IBM usw. usw. Und man würde erwarten, dass mit dem Aufkommen des inländischen Betriebssystems ala Linux diese Liste durch inländische Entwicklungen oder Modifikationen erweitert wird. Das ist aber nicht. Nein, dies ist nicht unbedingt ein inländischer Browser oder E-Mail-Client in diesen Distributionen. Aber ich würde mir wünschen, dass etwas unter Berücksichtigung der russischen Realitäten in der digitalen Wirtschaft endgültig festgelegt wird. Lassen Sie uns darüber nachdenken.

Sie werden mir sagen: "Warum, was passt nicht zu dir von dem, was ist?" Erstens, wenn wir nichts beitragen, warum nennen wir dann "inländische Software"? Nur weil es bestenfalls in Russland gelagert wird? Schauen wir uns als Beispiel die Verwendung von elektronischen X509-Zertifikaten, elektronischen Signaturen, Dokumentenverschlüsselung und Datenverkehr (tls / https) an. Und eine sehr interessante Analyse hat mir dabei geholfen (in gewisser Weise kann ich ihm nicht zustimmen, aber dies ist besonders), die Probleme bei der Verwendung von EDS-Tools, auf die Linux-Benutzer stoßen. Hier ist eine der Schlussfolgerungen:
In einigen Fällen empfehlen Entwickler von Portalen, die öffentliche Dienste bereitstellen, die Verwendung von Betriebssystemen, die nicht in der Registrierung enthalten sind, sowie von Software und Konfigurationen, die die Sicherheit von Benutzerdaten absichtlich verringern.
Unter den Worten "Nicht-Registrierungs-Betriebssysteme" müssen wir natürlich MS Windows verstehen. Der Standard unter den Portalen staatlicher und anderer Dienste sollte als Standardportal öffentlicher Dienste betrachtet werden. Sie können damit mit jedem inländischen Betriebssystem der Linux-Familie arbeiten. Und nur, dass das von ihm vertriebene Plugin den PKCS # 11-Standard für Token / Smartcards unterstützt und dies das Betriebssystem unabhängig macht. Für MS Windows bietet es Unterstützung für den MS CSP-Standard mit russischen kryptografischen Algorithmen. Und alle. Es (das Gosuslug-Plugin) schreibt keinen kryptografischen Anbieter (ob CSP oder PKCS # 11) des einen oder anderen Herstellers vor, sondern prüft, ob der kryptografische Anbieter dem Standard entspricht. Und warum sich diese positive Erfahrung nicht auf andere Abteilungen erstreckt, ist ein Rätsel. Darüber hinaus ist die Praxis von Plugins immer noch bösartig, sie bindet den Benutzer auf die eine oder andere Weise an bestimmte Betriebssysteme und sogar an Browser. Dieser Browser unterstützt diese Plugins (die ein CAPICOM kostet), dieses jedoch nicht usw. Warum nicht während des Vorgangs eine Authentifizierung benötigen, damit der Benutzer dem von ihm signierten Portal seine Mittel, seine Visitenkarte oder ähnliches zur Verfügung stellt?

Das erste, was getan werden muss, ist, Dienstportale vom Betriebssystem und den Krypto-Anbietern unabhängig zu machen, einschließlich der Aktualisierung des State Services-Portals.
Und heute ist es lächerlich, dass das gesamte Unternehmen unter dem inländischen Betriebssystem (einschließlich Buchhaltung) arbeitet, aber es verfügt über einen speziellen Computer mit MS Windows, um auf den Federal Tax Service zuzugreifen (erfordert GOST tls / https).

Oben haben wir über Verbesserungen im heimischen Betriebssystem gesprochen. Zurück zu ihnen. Warum und warum sie gebraucht werden. Nachdem der russische Verbraucher heute ein inländisches Betriebssystem gekauft und am Arbeitsplatz installiert hat, erhält er aus Sicht der russischen Kryptographie nichts mehr: Er kann keine Zertifikatsanforderung erstellen (die hier so gut geschrieben ist ), kein normales GOST-Zertifikat anzeigen, kein Dokument unterschreiben oder keinen Scheck ausstellen Unterschrift, schützen Sie Ihre E-Mail nicht. Es stellt sich sofort die Frage: „Was habe ich erworben? Wäre es nicht einfacher, die Linux-Distribution im Internet herunterzuladen, zumal sie sich ständig weiterentwickelt? " Im Westen oder Osten erhalten Menschen, die das Betriebssystem erwerben (nicht unbedingt für Geld), sofort eine Reihe nützlicher Dienste. Und wo sind unsere Linux-Distributionen mit Browsern oder E-Mail-Clients, die russische Kryptografie verwenden, wo sind die Dienstprogramme, die die vom Federal Tax Service bereitgestellte elektronische Signatur im Auszug aus dem Unified State Register of Legal Entities überprüfen können? Usw. Solche Distributionen sind mir nicht bekannt. Deshalb nehme ich das Mageia-Verteilungskit und befestige alles daran, worüber ich hier schreibe:



Wie Zertifikate gespeichert und Schlüssel in den meisten Linux-Anwendungen verwendet werden. Die überwiegende Mehrheit der Linux-Anwendungen (Mozilla, Google, LibreOffice, GnuPG usw. usw.) verwendet das NSS-Paket (Network Security Service) als Zertifikatspeicher:



Es wird auch davon ausgegangen, dass persönliche Zertifikate (Zertifikat plus privater Schlüssel) auf PKCS # 11-Token / Smartcards gespeichert sind. In diesem Fall ist es absolut nicht wichtig, ob es sich um ein Hardware-Token, eine Software oder sogar eine Cloud handelt. Dies ist eine Implementierung. Hauptsache, der PKCS # 11-Standard wird eingehalten. NSS speichert Stammzertifikate in seiner eigenen Datenbank. Es ist zu beachten, dass Mozilla, die Browserentwickler von Google, eine Liste vertrauenswürdiger Stammzertifikate bereitstellt. Leider gibt es in dieser Liste kein einziges russisches Stammzertifikat. NSS unterhält auch eine Datenbank mit Modulen (Bibliotheken), die für die Arbeit mit einem bestimmten Tokentyp verantwortlich sind. Das NSS-Paket ist OpenSSL in keiner Weise unterlegen, hat jedoch einen unbestreitbaren Vorteil: die Verfügbarkeit von Zertifikatdatenbanken.

Und was haben wir am Ende? Das NSS-Paket, das Teil der inländischen Linux-Betriebssystemdistributionen ist, unterstützt nicht die Arbeit mit inländischen PKCS # 11-GOST-Token. Dies führt dazu, dass Firefox und andere Programme nicht mit inländischen Token arbeiten möchten. Haben wir inländische Token mit integrierter Unterstützung für GOST? Es stellt sich heraus, dass es genug gibt. Dies sind Hardware-Token verschiedener Hersteller:



Leider wird die überwiegende Mehrheit der heutigen Hardware-Token als gewöhnliches Flash-Laufwerk zum Speichern von Schlüsseln und Zertifikaten verwendet.
Es gibt auch frei verteilte Software-Token, sowohl nicht zertifiziert als auch zertifiziert:



Und sogar PKCS # 11 Cloud-Token sind verfügbar:



Es ist bedauerlich, dass das NSS-Paket, das eine Reihe von Dienstprogrammen enthält, Fehler enthält, die manchmal nur auf GOST-Zertifikaten (pp- und calgoid-Dienstprogramme) auftreten.
Und es wäre großartig, wenn die inländischen Distributionen das NSS-Paket enthalten würden, das die Arbeit mit PKCS # 11-Token mit GOST-Kryptographie unterstützt. Sie können Einwände gegen mich erheben, es ist schwierig, teuer usw. Aber wenn die Entwickler interessiert waren, wussten sie, dass 2010 ein Fehler bei GOST für NSS registriert wurde. Ich selbst verfolge NSS und füge GOST-Unterstützung ab Version NSS-3.11 und bis jetzt NSS-3.41 hinzu. Und mit wem ich mich über die Jahre einfach nicht getroffen habe (jeder kann zählen), ist das Ergebnis Null. Ich mag die Antwort: - "Und sie dort im Westen hinzugefügt?". Aber das müssen sie nicht. Und es stellt sich heraus, dass wir es auch sind.

Und jetzt, wenn NSS mit Unterstützung für GOSTs in inländischen Distributionen wäre, wäre es mit wenig Blut möglich, Unterstützung für GOSTs in Firefox, Thunderbird, KMail, LibreOffice usw. hinzuzufügen. Und darüber wurde sowieso auf den Seiten von Habr geschrieben. Ja, ich habe OpenSSL mit GOST fast verpasst. Es gibt auch vom FSB Russlands zertifizierte Versionen. Und openssl mit GOSTs führt fast automatisch zum Erscheinen von openvpn-Versionen auf GOSTs in inländischen Distributionen:

Bild

Fügen Sie Apache mit tls / https-Unterstützung auf GOST hinzu, und PHP mit GOST wird nicht schaden.
Und in den Händen eines Benutzers des inländischen Betriebssystems gäbe es bereits Dienstprogramme für openssl und p7sign / p7verify zum elektronischen Signieren von Dateien. Aber es hätte ein Cleopatra-Grafikprogramm für denselben Zweck und eine GUI für NSS gegeben.

Um eine Zertifikatanforderung zu erstellen, können Sie das Dienstprogramm guicreate_csp verwenden:



Und wenn jemand ein Zertifizierungszentrum in seinem Unternehmen einrichten möchte, dann bitte:



Jemand könnte Zertifizierung sagen? Und im Westen verkaufen und verwenden sie zertifiziertes Linux? Nein, natürlich. Schließlich sind alle inländischen Hersteller aller oben genannten Produkte Teil zertifizierter Distributionen. Was verhindert, dass die Zertifizierung modifizierte Pakete enthält? Und welche coolen Distributionen wären für den Bildungsprozess in der Fachrichtung "Informationssicherheit" oder in Schulen geeignet. Meiner Meinung nach sollte auch das Ministerium für digitale Entwicklung, Kommunikation und Massenmedien der Russischen Föderation an einer Zertifizierung interessiert sein.
Und was ist die Schlussfolgerung? Ich erinnere Sie daran, dass wir über die elektronische Signatur gesprochen haben, über die Verwendung der heimischen Kryptographie.

Erstens sollte der Zugriff auf Portale nicht von der Art des verwendeten Betriebssystems oder Kryptografiedienstanbieters abhängen.

Zweitens sollten inländische Betriebssysteme Browser enthalten, die GOST https unterstützen.

Drittens sollten inländische Betriebssysteme E-Mail-Clients mit GOST-Unterstützung (Signieren / Verschlüsselung) enthalten.

Viertens sollte das inländische Betriebssystem eine elektronische Signatur und Verschlüsselung enthalten

Fünftens müssen inländische Betriebssysteme PKCS # 11-Token / Smartcards mit Unterstützung für russische Kryptografie unterstützen.

Wenn dieses Minimum erreicht ist, können wir von einem inländischen Betriebssystem wie Linux sprechen.
Und vor nicht allzu langer Zeit war ich in einem Ministerium, und dort sah ich eine einzigartige Importsubstitution: Ihnen wurde ein bestimmtes inländisches Linux angeboten, sie starteten eine virtuelle Maschine mit Windows und allen Schnickschnack, die im Ministerium unter Windows verwendet wurden, und sie sagten, Sie könnten über Importsubstitution berichten. Ich hoffe, mein letzter Absatz wird kein Leitfaden zum Handeln.

Das ist echt cool !!! Was wir einfach nicht haben!

Source: https://habr.com/ru/post/de434358/


All Articles