Signaturformate für elektronische Rechnungen

¨ Signaturformate fur elektronische Rechnungen Detlef H¨ hnlein1 und Ulrike Korte2 u 1 secunet Security Networks AG, Sudetenstraße 16, 96247 Michelau, detlef.huehnlein@secunet.com 2 Bundesamt f¨ r Sicherheit in der Informationstechnik, u Godesberger Allee 185 - 189, 53175 Bonn, ulrike.korte@bsi.bund.de Abstract: Der Einsatz von qualifizierten elektronischen Signaturen zur elektronischen ¨ Ubermittlung von Rechnungen gem¨ ß § 14 Abs. 3 [UStG] gewinnt in der Praxis zu- a nehmend an Bedeutung. Da die technischen Formate f¨ r qualifizierte elektronische u Signaturen nicht gesetzlich vorgeschrieben sind und f¨ r den Austauch der Rechnungs- u ¨ daten verschiedene Datenformate und Ubertragungswege genutzt werden, kommen ¨ bei der elektronischen Ubermittlung von Rechnungen verschiedenste Signaturformate ¨ ¨ zum Einsatz. Dieser Beitrag liefert einen Uberblick uber die wichtigsten Signaturfor- mate und gibt Empfehlungen welches Signaturformat in welchem Fall sinnvollerweise eingesetzt werden sollte. 1 Einleitung Da eine elektronische Rechnung gem¨ ß § 14 Abs. 3 [UStG] mit einer qualifizierten elek- a tronischen Signatur gem¨ ß § 2 Nr. 3 SigG [SigG] versehen sein muss, entwickelt sich die a ¨ elektronische Ubermittlung von Rechnungen in der Praxis zunehmend zu einem besonders wichtigen Einsatzgebiet der qualifizierten elektronischen Signatur. Anders als beispiels- weise in Italien [I-MfIT04] schreibt der Deutsche Gesetzgeber aber nicht vor, welche tech- nischen Formate f¨ r qualifizierte elektronische Siganturen einzusetzen sind. Deshalb kann u u ¨ f¨ r die Ubermittlung von Rechnungen grunds¨ tzlich jedes Signaturformat eingesetzt wer- a den, das unter Einsatz von sicheren Signaturerstellungseinheiten gem¨ ß § 2 Nr. 10 [SigG] a erzeugt werden kann sofern f¨ r den zugeh¨ rigen Signaturpr¨ fschl¨ ssel ein qualifiziertes u o u u Zertifikat existiert. Da f¨ r den Austauch von Rechnungsdaten verschiedene Datenformate u ¨ ¨ und Ubertragungswege genutzt werden, kommen bei der elektronischen Ubermittlung von Rechnungen in der Praxis auch verschiedenste Signaturformate zum Einsatz. ¨ ¨ Dieser Beitrag liefert einen Uberblick uber die wichtigsten Signaturformate im Umfeld der elektronischen Rechnung und ist folgendermaßen gegliedert: Abschnitt 2 stellt die wichtigsten Aspekte der verschiedenen Signaturformate vor. Nach der ausf¨ hrlichen Dis- u kussion der generischen, aus dem PKCS #7 Standard hervorgegangenen, Cryptographic Message Syntax (CMS) in Abschnitt 2.1 wird in Abschnitt 2.2 das darauf aufbauende S/MIME-Format f¨ r die Signatur von E-Mails erl¨ utert. Das f¨ r die Signatur von XML- u a u basierten Daten eingesetzte XML Digital Signatur Format wird in Abschnitt 2.3 erl¨ utert. a Der Standard f¨ r die Signatur von EDIFACT-Daten wird in Abschnitt 2.4 vorgestellt. In u Abschnitt 2.5 wird darauf eingegangen, wie PKCS #7 Signaturen in PDF-Dokumente in- tegriert werden k¨ nnen. o Abschnitt 3 enth¨ lt schließlich einfache Empfehlungen, in welchen Situationen welche a Signaturformate sinnvollerweise eingesetzt werden sollten. 2 Signaturformate Bei Signaturformaten kann in grober Art und Weise zwischen grundlegenden Low-Level- Signaturformaten und erweiterten High-Level-Signaturformaten unterschieden werden. Bei Low-Level-Signaturformaten ist spezifiziert, wie die zu signierenden Daten, oder ein Hash- wert derselben, vor der Anwendung des eigentlichen Signaturalgorithmus, z.B. durch Pad- ding-Mechanismen, aufzubereiten sind. Das Format selbst ist maßgeblich vom eingesetz- ten Kryptoalgorithmus (z.B. RSA, DSA, ECDSA) gepr¨ gt. a High-Level-Signaturformate umfassen die rohen Signaturdaten, wie sie durch das Low- Level-Signaturformat vorgegeben sind, sowie weitere Informationen, die bei der G¨ ltig- u keitspr¨ fung der Signatur herangezogen werden, wie z.B. den Zeitpunkt der Signaturer- u stellung und das zur Pr¨ fung der Signatur notwendige Zertifikat. u W¨ hrend anhand einer Signatur im Low-Level-Format nur die mathematische G¨ ltigkeit a u der Signatur gepr¨ ft werden kann, unterst¨ tzen die High-Level-Signaturformate in der Re- u u gel die komplette G¨ ltigkeitspr¨ fung von Signaturen und Zertifikaten sowie beispielsweise u u auch die Mehrfachsignatur. F¨ r den Einsatz zur Signatur von elektronischen Rechnungen ist die ausschließliche Ver- u wendung von Low-Level-Signaturformaten wenig geeignet, da sonst die f¨ r die Pr¨ fung u u der qualifizierten elektronischen Signatur zus¨ tzlich notwendigen Daten (Signaturerstel- a lungszeitpunkt, Zertifikat, Sperrinformationen, weitere Attribute etc.) in einer nicht stan- a ¨ dardisierten Art und Weise an den Empf¨ nger der Rechnung ubertragen werden m¨ ssten. u Deshalb werden im Folgenden die wichtigsten High-Level-Signaturformate f¨ r die elek- u ¨ tronische Ubermittlung von Rechnungen vorgestellt. 2.1 Cryptographic Message Syntax / PKCS #7 Mit der auf den PKCS #7 - Standard [PKCS7(v1.5)] zur¨ ckgehenden Cryptographic Mes- u sage Syntax (CMS) [RFC2630, RFC3369, RFC3852] wurde das in der Praxis vielleicht gebr¨ uchlichste Format f¨ r kryptographisch behandelte Nachrichten spezifiziert. a u Die Betrachtung des CMS-Standards ist in folgende Abschnitte gegliedert: • Containertypen f¨ r CMS u • Die Struktur von SignedData und SignerInfo • Abl¨ ufe bei der Erstellung und Pr¨ fung von Signaturen a u • Enveloping und Detached Signaturen mit CMS 2.1.1 ¨ Containertypen fur CMS Die CMS-Spezifikation sieht die Ablage von Nachrichten in ContentInfo-Containern vor. Diese Container haben jeweils einen bestimmten Typ, wobei in [RFC3852] folgende Containertypen definiert sind: • Data bezeichnet beliebige Daten. • SignedData wird f¨ r elektronische Signaturen verwendet und im folgenden n¨ her erl¨ utert. u a a • EnvelopedData enth¨ lt mit einem Nachrichtenschl¨ ssel verschl¨ sselte Daten und die Verschl¨ sselung a u u u des verwendeten Nachrichtenschl¨ ssels f¨ r den oder die Empf¨ nger. u u a • DigestedData enth¨ lt Daten, die zum Schutz der Integrit¨ t um einen Hashwert der Daten erg¨ nzt a a a wurden. • EncryptedData enth¨ lt verschl¨ sselte Daten. Anders als beim EnvelopedData-Typ wird hier al- a u lerdings der zur Verschl¨ sselung verwendete Nachrichtenschl¨ ssel nicht zus¨ tzlich u u a f¨ r die Empf¨ nger verschl¨ sselt. Das Schl¨ sselmanagement muss also auf einem u a u u anderen Weg geschehen. • AuthenticatedData enth¨ lt Daten, die mit einem Message Authentication Code (MAC) gesichert sind, a sowie die Verschl¨ sselung des zur MAC-Erzeugung verwendeten symmetrischen u Schl¨ ssels f¨ r einen oder mehrere Empf¨ nger. u u a • Weitere Containertypen k¨ nnen auch außerhalb der CMS-Spezifikation [RFC3852] definiert werden. Insbe- o sondere sind hier folgende zu nennen: – SignedAndEnvelopedData wurde in [PKCS7(v1.5), RFC2315] definiert und erlaubt es, Inhaltsdaten zu ¨ signieren und direkt danach zu verschl¨ sseln.