SQES – Schleupen Qualifizierte elektronische Signatur

Sichere & effiziente Kommunikation: Qualifizierte Elektronische Signatur von E-Mail Anhängen für E-Mail Lifecycle Management

Unser Anspruch an eine qualifizierte Signatur
Um die Funktionen wie in der Grafik beschrieben zu realisieren muss ein Signaturserver mindestens die u.a. Merkmale unterstützen. Die Gesamtverarbeitung muss den behördlichen Vorgaben zur Erfüllung der gesetzlichen Auflagen für den Vorsteuerabzug genügen.

Allgemeine Merkmale

• GoBS/GDPdU konformer Betrieb
• Audit/Testat für die Lösung muss vorhanden sein
• Kommunikation über TCP/IP
• Übergabe der Daten zwischen ELM- und Signatur-Server per SMTP
• Sichere Ergebnisdokumentation und Auswertung
• Regelwerk (Richtlinien) zur Steuerung der E Mail Verarbeitung
• Unterstützung der aktuellen RFC Standards

• Signatur der für die Marktkommunikation im Strom- und Gasmarkt relevanten Dateiformate (EDIFACT, PDF, XML)
• Signaturprüfung signierter Dateien (ankommende E Mails)
• Typ des Signaturzertifikats
• Gültigkeit des Signaturzertifikats
• Gültigkeit der Signatur
• Zertifikatsattribute (Textform) erkennen und „matchen“
  (Attribut kann unterschiedlich sein, auch bei gleichem Absender/Absenderdomäne) auf Attributszertifikate hinweisen
• Erstellen eines Prüfberichts über die Signaturprüfung und diesen als zusätzlichen E Mail Anhang einfügen
• positives oder negatives Ergebnis im Mail-Header dokumentieren
• Laut Kommunikationsrichtlinie der BNetzA ist es auch zulässig, die EDIFACT Daten gepackt als .zip oder .gzip zu versenden. Dabei ist es erforderlich, das jeweilige Archiv zu entpacken und eine Signaturdatei für den Inhalt des .zip/.gzip Archivs (eine EDIFACT Datei) zu erstellen. Die erstellte Signaturdatei wird dann ebenfalls in das .zip/.gzip Archiv abgelegt werden.
  Beim Empfang solcher gepackter Dateien wird analog verfahren. D.h. zip/gzip-Archiv entpacken, Signatur prüfen, Prüfbericht erstellen und dann den Prüfbericht dem zip/gzip-Archiv hinzufügen.

• möglichst weit kompatibel (alle BNA zugelassenen), mindestens
• TCOS (Telesec Netkey, E4-Netkey)
• Card-OS (TC Trustcenter, S-Trust, D-Trust)

• möglichst weit kompatibel (alle BNA zugelassenen), mindestens
• gemplus
• Kobil
• SCT-Reiner
• mehrere Kartenleser gleichzeitig
• für höheren Durchsatz
• Signaturkarten verschiedener STW (RZ-Kunden)

• Die realisierten Funktionen müssen den Vorgaben der aktuellen RFC Standards entsprechen.
• S/MIME Ent-/Verschlüsselung, Signatur/-prüfung, Signaturentfernung
• PGP/GnuPG Ent-/Verschlüsselung, Signatur/-prüfung, Signaturentfernung
• Unternehmenszertifikat (gemeinsames Zertifikat/Schlüsselmaterial für Benutzer/-gruppen)
• individuelle Signatur/Verschlüsselung an einzelnen AP
  Es ist möglich, dass einzelne Arbeitsplätze (z.B. Chef) trotz zentraler Lösung am Arbeitsplatz signieren / ver- und entschlüsseln.
  Abbildung im Regelwerk, z.B.
• Verschlüsseln mit best. Empfängern/Domains ist obligatorisch für alle, aber nicht für die Geschäftsleitung, weil die selbst signieren/verschlüsseln kann. Wenn der Geschäftsleitung aber eine unverschlüsselte Mail zu diesem Empfänger schickt, wird die Mail blockiert/abgelehnt bzw. mit den Standardschlüsseln signiert/verschlüsselt.
• Wenn E-Mails von best. Empfängern/Domains nur verschlüsselt und signiert entgegengenommen werden darf, so werden E-Mails an die Geschäftsleitung nicht entschlüsselt (zentral kein Schlüssel vorhanden) und trotzdem weitergeleitet (AV/AS - ungeprüft).
• Zertifikatsverwaltung
  Die zentral gehaltenen fortgeschrittenen Schlüssel/Zertifikate für die E Mail Signatur und Verschlüsselung (auch separate Schlüsselpaare) sind per GUI verwaltbar sein.
• Zertifikatsspeicher anzeigen
• Import
• Export
• verifizieren (manuell)
• Löschen (manuell)
• CRLs regelmäßig holen und interpretieren

• Formate (Content-Type), z.B. application/s-mime oder multipart
• Kodierung (Content-Transfer-Encoding), z.B. Base-64
• Algorithmen (Hash: SHA-1, MD5)
• Verfahren
• Signatur: id-dsa-with-sha1, RSA
• Inhaltsverschlüsselung (symm.): 3DES, AES128-256, RC2/40-168
• Schlüsselverschlüsselung (asymm.): RSA, Diffie-Hellmann
• Ref: RFC 3850/3851/3852 (S/MIME v3.1)
• Standardmäßig wird "clear signed" für E-Mail Signaturen verwendet, andere Verfahren aber einstellbar sein.
• Konfigurierbare Voreinstellung für alle Absender und Empfänger
• Konfigurationsmöglichkeit je E-Mail Adresse, Domain, Gruppe