Cloud Computing – digitale Schlüssel und Zertifikate

Selbst ist der Datenschützer
Kommentare

Cloud Computing steht synonym für „Zugriff immer und von überall“, denn die bereitgestellten Onlinedienste können jederzeit weltweit via Internet in Anspruch genommen werden. Da diese Dienste und die korrespondierenden Datenspeicher im Allgemeinen über den ganzen Globus verteilt sein können, besteht die Gefahr, dass persönliche Daten von unberechtigten Dritten abgegriffen und ausspioniert oder manipuliert werden. Wie schützt man sich also?

Selbst wenn von den Cloud-Providern deutsche Datenschutzgesetze beachtet werden, besteht die Gefahr des Datenmissbrauchs, wie der kürzlich bekanntgewordene NSA-Skandal überdeutlich gezeigt hat. Letztendlich ist man nur dann auf der sicheren Seite, wenn die Verschlüsselung der Daten eigenverantwortlich durchgeführt wird und somit nach dem Motto „selbst ist der Datenschützer“ gehandelt wird. Das bedeutet, dass als vertraulich eingestufte Daten lokal verschlüsselt werden, bevor sie im Rahmen eines Hochladevorgangs an einen Cloud-Anbieter übergeben werden, auch wenn dieser eine sichere Übertragung (SSL) und geschützte Cloud-Speicher (Verschlüsselung) garantiert.

Artikelüberblick

Der erste Teil dieser zweiteiligen Artikelserie gibt zunächst einen kurzen, einführenden Abriss über einige derzeit am Markt verfügbare Cloud-Technologien und deren funktionale Differenzierung. Im Anschluss daran befasst sich das Schwerpunktthema primär mit der Funktionalität „Onlinedatenspeicherung“, wobei anhand von zwei Beispielen das Einrichten und die Administration des jeweiligen Cloud-Speichers aufgezeigt werden. Daran anschließend werden grundlegende Sicherheitsaspekte bezüglich Datenübertragung und Datenspeicherung aufgezeigt, wobei insbesondere auf den Aspekt „Online“ eingegangen wird. Nachdem das Thema Sicherheit im Umgang mit digitalen Daten abgehandelt wurde, wird ein praktisches Beispiel für digitale Schlüssel und Zertifikate aufgezeigt.

IT-Dienste aus der Wolke

Mittlerweile umfasst der Terminus „Cloud Computing“ ein sehr breites Spektrum an zum Teil sehr unterschiedlichen Technologien. Angefangen bei einfachen Speicherlösungen, bis hin zu komplexen Diensten, deren Funktionsumfang mit dem eines klassischen Rechenzentrums durchaus vergleichbar ist. Einer der entscheidenden Vorteile dieser Cloud-Technologien ist in der nahezu beliebigen Skalierung bezüglich Speicherkapazität, Performance (Load Balancing), Ausfallsicherheit (Failover) und der kundenspezifischen Erweiterung, um Office- und Backofficekomponenten zu sehen. Darüber hinaus decken diese Onlinedienste auch das Back-up der gespeicherten Datenbestände ab. Diverse Softwarehersteller sind bereits dazu übergegangen, ihre Produkte nur noch via Cloud im Rahmen eines angepassten Lizenzmodells zur Nutzung zu überlassen.
Grundsätzlich werden Speicherlösungen ohne zusätzliche Funktionalität, also reine Onlinespeicher angeboten, die das Ablegen auch größerer Datenbestände ermöglichen. Derzeit wird beispielsweise ein 20 Gigabyte großer Onlinespeicher für ein bis zwei Euro pro Monat angeboten, wobei die Daten per FTP, FTPS oder WebDav transferiert werden können.
Darüber hinaus sind Speicherlösungen mit zusätzlicher Funktionalität verfügbar, die meist in Form eines Browserinterface bereitgestellt werden und neben einer Logon-Prozedur eine Dateiverwaltung beinhalten, mit der unter anderem zwischen zu veröffentlichenden und nicht zu veröffentlichenden Dateien unterschieden werden kann. Neben dieser in der Cloud befindlichen Serverkomponente wird meistens bei der Einrichtung eines solchen funktionalen Speichers auch eine lokale Komponente in Form eines Verzeichnisses eingerichtet, sodass durch einfaches Ziehen und Fallenlassen von Dateien in dieses Verzeichnis das Kopieren und das Synchronisieren von Bild- oder Textdateien relativ komfortabel vonstatten geht. Beispielsweise bietet Microsoft mit SkyDrive eine derartige Lösung, die das Onlinespeichern von Fotos und Dokumenten ermöglicht. Derzeit ist das Ganze bis zu einem Speichervolumen von 7 Gigabyte kostenlos.

SPI-Cloud-Dienste

Weiterhin haben sich zahlreiche Onlineportale etabliert, die SaaS (Software as a Service), PaaS (Platform as a Service), sowie IaaS (Infrastructure as a Service) bereitstellen. Diese drei Cloud-Dienste werden unter dem Akronym „SPI“ zusammengefasst.
SaaS beschreibt ein Modell, in welchem Anwendungen von einem Anbieter vorgehalten und typischerweise über das Internet verfügbar gemacht werden. Aus der Sicht des Kunden ergeben sich Vorteile wie einfache Administration, automatische zentrale Updates, sowie optimale Zusammenarbeit von an gemeinsamen Dokumenten arbeitenden Gruppen und natürlich der globale Zugriff auf Anwendungen und Ressourcen. PaaS bietet Funktionalitäten für die Entwicklung und den Test von Software sowie die Bereitstellung von Anwendungen. Das bedeutet, dass dem Entwickler ein umfangreiches Framework (IDE, Tools, Datenbanken, Middleware etc.) zur Verfügung gestellt wird, das ihm die Realisierung bzw. Implementierung von Geschäftsanwendungen für die Cloud ermöglicht. Das Entwicklungsframework wird hierbei von dem Anbieter auf dem aktuellen Stand gehalten, sodass sich der Entwickler nicht mit dem teilweise sehr aufwändigen Deployment seines eigenen Systems belasten muss.
IaaS bedeutet die Bereitstellung von skalierbarer Serverleitung, Speicher- und Rechenkapazitäten sowie Netzwerkdiensten durch einen externen Dienstleister. Der Kunde bekommt somit eine komplette IT-Infrastruktur, die genau auf seine Bedürfnisse bezüglich Systemarchitektur und Performance abgestimmt werden kann.

Abb. 1: Grundstruktur einer SPI-Architektur

Abbildung 1 zeigt die generelle Grundstruktur einer SPI-Architektur, wobei für jeden einzelnen Layer typische Komponenten und Leistungspakete angegeben sind. Fallweise lässt sich keine scharfe Abgrenzung zu den einzelnen Layern angeben, da die nachstehend beschriebenen APIs für den Dateitransfer einen Onlinespeicher aus dem Layer SaaS betreffen, die Entwicklung aber beispielweise innerhalb von PaaS stattfinden kann.
Die diversen Pakete beinhalten verschiedene Komponenten, wie beispielsweise spezielle Java- oder .NET-Plattformen, deren aktuelle Preise und Verfügbarkeiten den Angebotsseiten der einzelnen Anbieter entnommen werden können. Die zu den jeweiligen Leistungspakten gehörenden Komponenten sind bei den etablierten Internet-Hostern, Telekommunikationsunternehmen oder den Softwareriesen wie beispielsweise Microsoft oder Google erhältlich.

Onlinespeicher (Webspace)

Nachfolgend werden exemplarisch die beiden Onlinespeicher GDrive von Google und SkyDrive von Microsoft vorgestellt und einem qualitativen Kurzvergleich unterzogen. Wie bei allen Cloud-Diensten benötigt man einen Remote-Zugriff via Internet und einen entsprechenden Account. Ein derartiger Account kann für die beiden genannten Onlinespeicher durch eine einfache Registrierung angelegt werden. Nach erfolgreicher Registrierung und anschließender Anmeldung stellen beide Anbieter zu der reinen Speicherfunktionalität zusätzlich Applikationen wie Text- und Tabellenkalkulation sowie Terminplanung bereit.

SkyDrive von Microsoft

Um Microsoft SkyDrive nutzen zu können, benötigt man zunächst ein Microsoft-Konto. Hierfür kann entweder ein komplett neues Konto erstellt werden oder ein bereits vorhandenes E-Mail-Konto von Microsoft (xxx.yyy@outlook.com etc.) oder ein MSDN-Konto verwendet werden. Falls kein geeignetes Konto existiert, kann auf den Webseiten von Microsoft, die eine Anmeldung erfordern, mit dem Button „Jetzt registrieren“ ein Konto angelegt werden, wobei eine Freischaltung des Kontos erst nach einem erfolgreichen Sicherheitscheck via SMS erfolgt.
Gemäß Microsoft ist zwischen den beiden Komponenten „SkyDrive im Web“ und „SkyDrive auf dem lokalen Computer“ zu unterscheiden. Erstgenanntes ist nach erfolgreichem Anmelden als Browseranwendung verfügbar. Nach der allerersten Anmeldung ist nur ein leerer Dokumentenordner sichtbar und es werden auf der linken Seite das Menü und der verfügbare Speicherplatz angezeigt. Nachdem Dateien in Form von Bildern, Office-Dokumenten oder dergleichen direkt online kreiert oder hochgeladen wurden, stehen diese zur Verarbeitung oder Veröffentlichung zur Verfügung (Abb. 2). Bei „SkyDrive auf dem lokalen Computer“ handelt es sich um eine typische Clientanwendung, die es nicht nur als Windows-Applikation, sondern auch als App für mobile Android-Geräte oder iPhone/iPad gibt.

Abb. 2: SkyDrive-Browserinterface

Zunächst ist die Applikation oder die App herunterzuladen, wobei während dieses Vorgangs automatisch ein SkyDrive-Ordner erstellt wird. In diesen Ordner können alle Dateien, die mit SkyDrive synchronisiert werden sollen, kopiert oder durch Drag and Drop hinzugefügt werden. Dabei kann festgelegt werden, ob Bilder, Dokumente oder alle Dateien in die Synchronisierung einbezogen werden sollen. Alle synchronisierten lokalen Ordner und Dateien werden im Dateiexplorer mit einem grünen Häkchen gekennzeichnet.

Aufmacherbild: White clouds in blue sky von Shutterstock / Urheberrecht: photolinc

[ header = Seite 2: GDrive von Google ]

GDrive von Google

Ebenso wie bei dem zuvor beschriebenen SkyDrive wird auch bei Google ein Konto für die Nutzung von GDrive benötigt. Für die Anmeldung stellt Google ein Browserinterfacebereit, das auch die Erstellung eines neuen Kontos unterstützt. Nach erfolgreicher Anmeldung ist wie in Abbildung 3 gezeigt eine interaktive Benutzeroberfläche verfügbar, die das Herunterladen von „Google Drive für PC“ bereitstellt. Nach erfolgreichem Download erfolgt eine schrittweise Installation auf dem lokalen System. Zuerst wird ein spezieller Ordner kreiert und daran anschließend können die mit GDrive zu synchronisierenden Elemente ausgewählt und die Startbedingungen für die Synchronisation festgelegt werden. Beispielweise kann die Synchronisation automatisch beim Starten des Computers angestoßen werden, sodass alle GDrive-Dateien mit den lokalen Dateien synchronisiert sind.

Abb. 3: GDrive-Browserinterface

Weiterhin werden während der Installation vier lokale Applikationen und die zugehörigen Icons erstellt. Hierbei handelt es sich um eine browserbasierte Textverarbeitung (Google Docs), eine browserbasierte Tabellenkalkulation (Google Sheets) und eine browserbasierte Präsentationssoftware (Google Slides). Einen lokalen Dateiexplorer startet die Applikation Google Driver. Ein Kalender und ein Adressbuch stehen nicht zur Verfügung, da hierfür Google andere spezielle Applikationen anbietet.
Für sämtliche auf GDrive gespeicherten Dateien können differenzierte Freigaben vergeben werden, wobei insbesondere andere Nutzer berücksichtigt werden können. Unterschieden wird zwischen „darf bearbeiten“, „darf kommentieren“ und „darf lesen“. Der Freigabeprozess erfordert die Angabe der E-Mail-Adresse desjenigen, der die Berechtigung erhalten soll. Google bezeichnet diesen Vorgang als „Personen einladen“. Eingeladene Personen erhalten eine E-Mail, in der ein Link auf die freigegebenen Objekte enthalten ist.
Auf mobilen Smartphones oder Tablets kann auf die im Onlinespeicher abgelegten Dateien zugegriffen werden, ohne dass eine spezielle App installiert sein muss. Die Synchronisation erfolgt prinzipiell in Echtzeit. Wird beispielsweise eine online gespeicherte Textdatei mit Google Docs bearbeitet, dann kann man nach erfolgreicher Anmeldung bei GDrive mit einem Tablet diese Textdatei ebenfalls öffnen und die Änderungen direkt (live) mitverfolgen.

Datensicherheit

Während lokal gespeicherte Daten durch eine selbstdefinierte Sicherheitsrichtlinie geschützt werden können, sind extern zu speichernde Daten bereits bei der Übertragung via Internet gewissen Gefahren ausgesetzt, da auf öffentliche Netze jedermann Zugriff hat. Das Gefahrenpotenzial erhöht sich um ein weiteres, wenn die Daten auf fremden Onlinespeichern gespeichert werden, da keinerlei externe Kontrollmöglichkeiten bestehen und auf die proklamierten Sicherheitsstandards des Anbieters vertraut werden muss.
Zum Schutz von sensitiven digitalen Daten bieten sich folgende grundlegenden Basissicherheitsstandards basierend auf Vertraulichkeit und Integrität an. Vertraulichkeit gewährleistet, dass die durch ein technisches System zu verarbeitenden oder zu übertragenden Daten durch Verschlüsselung vor unberechtigten Zugriffen geschützt werden. Basierend auf digitalen Signaturen definiert Integrität eine manipulationssichere Verarbeitung sowie den Austausch digitaler Daten.
Grundsätzlich existieren neben den beiden zuletzt beschriebenen generellen Sicherheitsstandards eine Reihe weiterer Optionen bezüglich der Absicherung des Übertragungskanals (VPN, IPsec. etc.) oder des Schutzes gespeicherter Daten (TrueCrypt, Bitlocker etc.). Allerdings müssen derartige Schutzmechanismen vom jeweiligen Provider angeboten bzw. unterstützt werden, sodass diese nur sehr bedingt zur Anwendung kommen können.

Digitale Schlüssel

Die technische Realisierung der zuletzt angesprochenen Prädikate Vertraulichkeit und Integrität basiert auf digitalen Schlüsseln und Zertifikaten. Für das Ver- und Entschlüsseln von Daten finden digitale Schlüssel Verwendung, wobei zwischen symmetrischen und asymmetrischen Schlüsseln unterschieden wird. Im Folgenden geht es primär um die asymmetrischen, da diese die Grundlage für eine zertifikatsbasierte PKI (Public Key Infrastructure) darstellen.
Während bei den symmetrischen Verfahren ein und derselbe Schlüssel für das Ver- und Entschlüsseln verwendet wird, basieren asymmetrische Verfahren auf zwei mathematisch korrelierten Schlüsseln. Hierbei wird zwischen dem öffentlichen Schlüssel (Public Key) und dem privaten Schlüssel (Private Key) unterschieden. Derzeit finden in der Praxis zwei unterschiedliche asymmetrische Verfahren Anwendung, nämlich das RSA- und das ECC-Kryptosystem. Die Abkürzung RSA leitet sich von den Anfangsbuchstaben der Nachnamen der Begründer (Rivest, Shamir, Adleman) ab, die dieses Verfahren bereits 1977 publiziert haben. ECC steht für Eliptic Curve Cryptography und wurde bereits 1985 von Neal Koblitz und Victor Miller unabhängig voneinander vorgestellt.
Obwohl die Algorithmen beider kryptographischer Verfahren auf völlig unterschiedlichen mathematischen Operationen basieren, ist der Formalismus für die Verschlüsselung/Entschlüsselung von Daten und die Generierung/Verifikation von Signaturen in beiden Systemen identisch. Das heißt, Entschlüsselung von Daten und Generieren einer Signatur erfolgt mit dem privaten Schlüssel, Verschlüsselung und Verifikation einer Signatur wird mit dem öffentlichen Schlüssel vorgenommen.
Das mit asymmetrischen Kryptosystemen erreichbare Sicherheitsniveau hängt nicht nur von der verwendeten Schlüssellänge ab, sondern in hohem Maße von der sicheren Generierung und Speicherung des privaten Schlüssels. Hierzu bieten sich hardwarebasierte Lösungen an, nämlich so genannte HSM (Hardware Security Module) oder Chipkarten. Weiterhin kann auf einen Schlüsselspeicher in Form einer speziellen Datei (Keystore) zurückgegriffen werden, wenn der geforderte Securitylevel dies zulässt. In allen Fällen sollte der private Schlüssel den Keystore nicht unverschlüsselt verlassen.
Der öffentliche Schlüssel kann hingegen ohne Einschränkung an Dritte weitergegeben werden. Aus Gründen der Interoperabilität erfolgt diese Weitergabe in standardisierter Form, genauer gesagt eingeschlossen in einem digitalen Zertifikat des Formats X.509.

Digitale Zertifikate

Der derzeitige De-facto-Standard für digitale Zertifikate wird mit X.509 bezeichnet und ist in RFC5280 umfassend spezifiziert. Prinzipiell handelt es sich bei einem digitalen Zertifikat um ein elektronisches Dokument (Datei), das neben den Daten des Ausstellers und des Antragstellers den öffentlichen Schlüssel des Antragstellers, sowie Angaben bezüglich der verwendeten kryptographischen Algorithmen enthält. Weiterhin sind die Gültigkeit des Zertifikats und einige Erweiterungen (Extensions) enthalten.

Abb. 4: X.509-Zertifikat

Da die Zertifikatsdaten nicht als Text gespeichert sind, sondern binär im Format ASN.1 (Abstract Syntax Notation) kodiert abgelegt sind, wird ein spezielles Tool zur Visualisierung eines X.509-Zertifikats benötigt. Abbildung 4 zeigt exemplarisch die Details eines X.509-Zertifikats unter Zuhilfenahme des Zertifikat-Viewers von Windows.
Die praktische Anwendung von digitalen Schlüsseln und Zertifikaten sei zusammenfassend an einem kurzen Beispiel veranschaulicht: Ein Anwalt signiert mit seinem privaten Schlüssel ein Dokument und sendet dieses zusammen mit der Signatur in elektronischer Form zu einem oder mehreren Mandanten. Sein Zertifikat stellt er zum Download bereit und veröffentlicht die zugehörige Prüfsumme (Fingerabdruck). Ein Mandant lädt das Zertifikat herunter und überprüft die Echtheit mithilfe der veröffentlichten Prüfsumme. Anschließend verifiziert der Mandant die digitale Signatur des Dokuments mit dem im Zertifikat enthaltenen öffentlichen Schlüssel des Anwalts. Durch diese Maßnahme ist die Integrität des elektronischen Dokuments gewährleistet. Für den Fall, dass zusätzlich auch Vertraulichkeit gewährleistet sein muss, sind die Daten zu verschlüsseln.

[ header = Seite 3: Standardschlüsseldateien ]

Standardschlüsseldateien

Für die Speicherung und die Weitergabe von asymmetrischen Schlüsseln sind die beiden Industriestandards PKCS#8 und PKCS#12 geeignet, wobei das Akronym PKCS für Public Key Cryptography Standard steht. Diese Standardisierung gewährleistet die Interoperabilität über Systemgrenzen hinweg, sodass beispielsweise ein definierter Austausch zwischen einem Unix-Betriebssystem und einem Windows-Betriebssystem problemlos vonstatten gehen kann.
Der erstgenannte Standard PKCS#8 ist in RFC 5208 unter dem Titel „Private-Key Information Syntax“ spezifiziert. Genauer betrachtet wird hier eine ASN.1-Datensequenz definiert, in der ein privater Schlüssel unverschlüsselt oder verschlüsselt in einer Datei gespeichert werden kann. Zusätzlich sind in dieser Sequenz die Versionsnummer, der kryptographische Algorithmus und optionale Attribute enthalten. Diese Sequenz trägt im unverschlüsselten Fall den Namen „PrivatKeyInfo“. Falls die Schlüsseldaten verschlüsselt gespeichert sind, wird die Sequenz als „EncryptedPrivatKeyInfo“ bezeichnet, und es ist immer ein Passwort erforderlich, bevor auf den privaten Schlüssel zugegriffen werden kann. Der korrespondierende öffentliche Schlüssel und/oder ein Zertifikat können in diesem Format nicht gemeinsam mit dem privaten Schlüssel gespeichert werden.
Hierzu eignet sich der Standard PKCS#12, der derzeit als RFC-Entwurf (Draft) unter dem Titel „Personal Information Exchange Syntax“ vorliegt und im gleichnamigen RSA-Dokument detailliert spezifiziert ist. Hier wird eine Sequenz namens PFX definiert, die sämtliche erforderlichen und optionalen Größen in Form von untergeordneten Sequenzen und einfachen Datentypen enthält. Obwohl es nicht zwingend erforderlich ist, wird eine PKCS#12-Datei per Konvention mit dem Suffix „.pfx“ oder „.p12“ gekennzeichnet.

PKCS#12Creator

Das nachstehend beschriebene Visual-Studio-Projekt „PKCS12Creator.sln“ verdeutlicht die in den letzten Abschnitten dargelegten theoretischen Grundlagen bezüglich Generierung digitaler Schlüssel und Zertifikate sowie die Speicherung in Standardschlüsseldateien. Als Standard kommt hier PKCS#12 zur Anwendung, da in diesem Format auch der öffentliche Schlüssel und ein X.509-Zertifikat gemeinsam gespeichert werden können, sodass der komplette digitale Datensatz in Form einer einzelnen Datei archiviert oder geschützt transportiert werden kann.
Die erforderlichen kryptographischen Operationen werden von dem Bouncy Castle API für CSharp abgedeckt. Hierbei handelt es sich um eine freiverfügbare Bibliothek für C#. Eine kompilierte Version liegt als DLL „crypto.dll“ im Projektverzeichnis. Diese muss als Verweis dem Projekt hinzugefügt werden.
Listing 1 zeigt, wie einfach es ist, mit nur wenigen Zeilen Code ein asymmetrisches RSA-Schlüsselpaar (2 048 Bit) zu generieren. In dieser Beispielsequenz ist das Schlüsselpaar in der Instanz cipherKeyPair gespeichert und kann später zur Signierung der Zertifikatsdaten verwendet werden.

int Strength = 2048;
RsaKeyPairGenerator rsaGenerator = new RsaKeyPairGenerator();
RsaKeyGenerationParameters rsaKeyGenerationParameters = 
  new RsaKeyGenerationParameters(BigInteger.ValueOf(0x11), 
  new SecureRandom(), Strength, 25);
rsaGenerator.Init(rsaKeyGenerationParameters);
AsymmetricCipherKeyPair cipherKeyPair = rsaGenerator.GenerateKeyPair();

Die Klasse X509V3CertificateGenerator stellt die Grundlage für das Generieren eines Zertifikats gemäß X.509-Standard dar. Wie aus Listing 2 hervorgeht, werden zunächst Zertifikatserweiterungen (X509Extensions) und daran anschließend der Name des Zertifikatsausstellers (Issuer) sowie der Name des Zertifikatsantragstellers (Subject) hinzugefügt. Des Weiteren werden noch eine Gültigkeitsperiode und eine Seriennummer definiert, bevor abschließend der im Zertifikat zu speichernde öffentliche Schlüssel und der zu verwendende Signaturalgorithmus gesetzt werden. Letztendlich wird das Zertifikat durch den Aufruf von „Generate“ generiert und in der Klasse X509Certificate gespeichert.

X509V3CertificateGenerator certGen = new X509V3CertificateGenerator();
certGen.AddExtension(X509Extensions.BasicConstraints, true, new BasicConstraints(0));
...
Hashtable attrsIssuer = new Hashtable();
ArrayList orderIssuer = new ArrayList();
attrsIssuer.Add(X509Name.CN, tbIssuerCN.Text);
orderIssuer.Add(X509Name.CN);
...
Hashtable attrsSubject = new Hashtable();
ArrayList orderSubject = new ArrayList();
attrsSubject.Add(X509Name.CN, tbSubjectCN.Text); 
orderSubject.Add(X509Name.CN); 
... certGen.SetNotBefore(DateTime.Parse(dtpValidFrom.Value.ToShortDateString(), culture));
certGen.SetNotAfter(DateTime.Parse(dtpValidTo.Value.ToShortDateString(), culture)); 
certGen.SetSerialNumber(new BigInteger("987654321"));
certGen.SetIssuerDN(new X509Name(orderIssuer, attrsIssuer));
certGen.SetSubjectDN(new X509Name(orderSubject, attrsSubject));
certGen.SetPublicKey(cipherKeyPair .Public);
certGen.SetSignatureAlgorithm(sSignatureAlgorithm);

X509Certificate x509Cert = certGen.Generate(cipherKeyPair .Private);

Nachdem sowohl das RSA-Schlüsselpaar als auch das X.509-Zertifikat generiert wurden, kann das Speichern in eine PFX- bzw. P12-Datei gemäß Listing 3 vorgenommen werden. Der Klasse Pkcs12Store ist lediglich ein gültiger FileStream zu übergeben, um mit der Methode store unter Angabe eines Passworts das Speichern einzuleiten. Während in Listing 3 ungeachtet dessen, ob bereits eine PFX-Datei mit dem angegebenen Namen existiert, gespeichert wird, ist im vorliegenden Visual-Studio-Projekt PKCS12Creator.sln diesbezüglich eine Fallunterscheidung kodiert.

FileStream fs = new FileStream("Filename", FileMode.Create);
Pkcs12Store store = new Pkcs12Store();
store.SetKeyEntry("PKCS12Creator", new AsymmetricKeyEntry(cipherKeyPair
  .Private), 
new X509CertificateEntry(x509Cert));
store.Save(fs, "Password".ToCharArray(), new SecureRandom());

Abbildung 5 zeigt den PKCS#12Creator in Aktion. Neben der Auswahl einer Schlüssellänge sind ein Passwort und ein Dateiname, unter dem die PFX-Datei gespeichert werden soll. Weiterhin sind der Name des Ausstellers und der Name des Antragstellers einzugeben, wobei es sich hier um den Standard gemäß X.500 handelt. Während CN, O und OU individuell gewählt werden können, muss C (Country) gemäß internationaler Konvention für Top-Level-Namen den Ländercode repräsentieren und somit aus genau zwei Buchstaben bestehen. Der Gültigkeitszeitraum hängt von der jeweiligen Anwendung des Zertifikats ab und wurde im gezeigten Beispiel auf fünf Jahre gesetzt.

Abb. 5: PKCS#12Creator in Aktion

Nachdem durch Anklicken der Schaltfläche „Generieren und Speichern“ eine Datei mit dem Suffix P12 generiert wurde, lässt sich durch einen Doppelklick auf den Dateinamen im Dateiexplorer ein Zertifikatimportassistent starten, mit dem exemplarisch die Kompatibilität der erstellten P12-Datei überprüft werden kann. Zunächst muss ausgewählt werden, ob das zu importierende Zertifikat nur für den aktuellen Benutzer oder den lokalen Computer verfügbar sein soll und ggf. im Anschluss daran die zu importierende Zertifikatsdatei. Daran anschließend ist das Passwort einzugeben, welches bei der Erstellung der P12-Datei verwendet wurde. Ebenfalls optional kann ein bestimmter Windows-Zertifikatsspeicher ausgewählt werden. Abschließend stellt der Zertifikatimportassistent eine Zusammenstellung bereit und es kann der Import durch Anklicken der Schaltfläche „Fertig stellen“ gestartet werden.
Ob der Import erfolgreich verlaufen ist, kann man mit dem Zertifikatmanger überprüfen, der durch Eingabe von certmgr.msc gestartet werden kann. Wenn der Import erfolgreich verlaufen ist, dann wird das Zertifikat in einer Auswahlliste dargestellt, und es kann durch einen Doppelklick angezeigt werden (vgl. Abb. 4).

Ausblick

Der zweite Teil dieser Artikelserie (GDrive-API – Kryptofunktionalitäten fürs Ver- und Entschlüsseln) zeigt zunächst die grundlegenden Möglichkeiten der SkyDrive- und GDrive-APIs bezüglich des Hochladens und Herunterladens von Dateien auf. Weiterhin wird eine Applikation mit Quellcode vorgestellt, die das API von GDrive exemplarisch veranschaulicht und die kryptographischen Funktionalitäten für das Ver- und Entschlüsseln von lokalen Dateien aufzeigt.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -