Abstract Syntax Notation One ( ASN.1 ) ist eine Standardschnittstellen-Beschreibungssprache zum Definieren von Datenstrukturen, die plattformübergreifend serialisiert und deserialisiert werden können. Es wird in der Telekommunikation und in der Computervernetzung und insbesondere in der Kryptographie breit eingesetzt.
Protokollentwickler definieren Datenstrukturen in ASN.1-Modulen, bei denen es sich im Allgemeinen um einen Abschnitt eines umfassenderen Normungsdokumentes handelt, das in der Sprache ASN.1 geschrieben ist. Der Vorteil ist, dass die ASN.1-Beschreibung der Datencodierung unabhängig von einer bestimmten Computer- oder Programmiersprache (außer ASN.1.) Ist. Da ASN.1 sowohl vom Benutzer als auch von der Maschine lesbar ist, kann ein ASN.1-Compiler verwendet werden kompilieren Sie Module in Codebibliotheken (CODECs), die die Datenstrukturen decodieren oder codieren. Einige ASN.1-Compiler können Code zum Codieren oder Decodieren mehrerer Codierungen erzeugen, z. verpackt, BER oder XML.
ASN.1 ist ein gemeinsamer Standard der Internationalen Organisation für Normung (ISO), der Internationalen Elektrotechnischen Kommission (IEC) und des Telekommunikationsstandardisierungssektors (ITU-T) der International Telecommunication Union (ITU-T), der 1984 als Teil von CCITT X definiert wurde. 409: 1984. [1] 1988 wurde ASN.1 aufgrund seiner breiten Anwendbarkeit zu seinem eigenen Standard X.208 . Die grundlegend überarbeitete Version von 1995 wird von der Serie X.680 [2] abgedeckt. Die neueste Version der X.680-Empfehlungsreihe ist die 5.0-Ausgabe, die 2015 veröffentlicht wurde.
Sprachunterstützung [ edit ]
ASN.1 ist eine Datentypdeklarationsnotation. Es definiert nicht, wie eine Variable eines solchen Typs bearbeitet wird. Dies ist tatsächlich in anderen Sprachen definiert, z. B. SDL (Specification and Description Language) für die ausführbare Modellierung oder TTCN-3 (Testing and Test Control Notation) für Konformitätsprüfungen. Diese beiden Sprachen unterstützen nativ ASN.1-Deklarationen. Es ist möglich, ein ASN.1-Modul zu importieren und eine Variable eines der im Modul deklarierten ASN.1-Typen zu deklarieren.
Anwendungen [ edit ]
ASN.1 wird in sehr unterschiedlichen Anwendungen wie Paketverfolgung, Stromverteilung und Biomedizin verwendet. Sein umfangreichster Einsatz findet weiterhin in Standard-Telekommunikationsprotokollen statt, wie z. B. intelligente Netzwerke, UMTS, Voice over IP, interaktives Fernsehen und HiperAccess.
In X.509 wird ASN.1 verwendet, das das Format der Zertifikate definiert, die im HTTPS-Protokoll für das sichere Surfen im Internet und in vielen anderen kryptografischen Systemen verwendet werden.
Es wird auch in der PKCS-Gruppe von Kryptographiestandards verwendet: X.400 E-Mail, X.500 und LDAP (Lightweight Directory Access Protocol), H.323 (VoIP), Kerberos, BACnet, SNMP (Simple Network Management Protocol). und drahtlose Kommunikationstechnologien der dritten und vierten Generation (UMTS, LTE und WiMAX 2). [3]
Encodings [ edit
ASN.1 ist eng mit einer Menge von assoziiert Codierungsregeln, die angeben, wie eine Datenstruktur als eine Reihe von Bytes dargestellt wird. Die Standard-Codierungsregeln für ASN.1 umfassen:
Die Kodierungsregeln sind alle plattformunabhängig und können für eine Vielzahl von Hardware und Software verwendet werden.
Das PEM-Format wird häufig verwendet, um DER-codierte ASN.1-Zertifikate und -Schlüssel in einem Nur-ASCII-Format zu kapseln. Die PEM-Version einer DER-Nachricht besteht aus der base64-Codierung der DER-Nachricht, vorangestellt "----- BEGIN FOO -----", gefolgt von "----- END FOO -----". "wo" FOO "" ZERTIFIKAT "," ÖFFENTLICHER SCHLÜSSEL "," PRIVATER SCHLÜSSEL "oder viele andere Arten von Inhalten angeben kann.
Codierungssteuerungsnotation [ edit ]
ASN.1-Empfehlungen enthalten eine Reihe von vordefinierten Codierungsregeln. Wenn keine der vorhandenen Codierungsregeln erfüllt ist, bietet die Codierungssteuerungsnotation dem Benutzer die Möglichkeit, eine eigene benutzerdefinierte Codierungsregel zu definieren.
Allgemeine String-Codierungsregeln [ edit ]
Generische String-Codierungsregeln (GSER) sind ein Satz von ASN.1-Codierungsregeln zum Erzeugen einer ausführlichen, menschlichen lesbare Texttransfersyntax für Datenstrukturen, die in ASN.1 beschrieben werden. Der Zweck von GSER besteht darin, dem Benutzer verschlüsselte Daten oder Eingabedaten des Benutzers in einem sehr einfachen Format darzustellen. GSER wurde ursprünglich für das LDAP-Protokoll (Lightweight Directory Access Protocol) entwickelt und wird außerhalb davon selten verwendet. Von der Verwendung von GSER in tatsächlichen Protokollen wird abgeraten, da nicht alle von ASN.1 unterstützten Zeichenkettencodierungen darin reproduziert werden können. Die GSER-Codierungsregeln sind in RFC 3641 angegeben und werden im Gegensatz zu anderen gebräuchlichen Typen von Codierungsregeln von ITU-T nicht standardisiert.
Gepackte Kodierregeln [ edit ]
Gepackte Kodierregeln (PER) sind ASN.1-Kodierregeln zum Erzeugen einer kompakten Übertragungssyntax für Datenstrukturen, die in beschrieben sind ASN.1, 1994 definiert.
Diese Empfehlung oder Internationale Norm beschreibt eine Reihe von Codierungsregeln, die auf Werte aller ASN.1-Typen angewendet werden können, um eine wesentlich kompaktere Darstellung zu erreichen als durch die BER und ihre Ableitungen (beschrieben in ITU-T Rec. No. X.690 (ISO / IEC 8825-1).
Es verwendet zusätzliche Informationen, wie z. B. die Unter- und Obergrenzen für numerische Werte, aus der ASN.1-Spezifikation, um die Dateneinheiten mit der minimalen Anzahl von Bits darzustellen. Die Kompaktheit erfordert jedoch, dass der Decodierer die vollständige abstrakte Syntax der zu decodierenden Datenstruktur kennt.
Es gibt zwei Variationen gepackter Codierungsregeln: nicht ausgerichtet und ausgerichtet. Bei der nicht ausgerichteten Codierung werden die Bits ohne Rücksicht auf Oktett- (Byte-) Grenzen gepackt. Bei der ausgerichteten Codierung werden bestimmte Typen von Datenstrukturen an Oktettgrenzen ausgerichtet, was bedeutet, dass es eine Anzahl von verschwendeten Füllbits gibt. Bei der nicht ausgerichteten Codierung wird die geringste Anzahl von Bits verwendet, jedoch voraussichtlich mit einem gewissen Verarbeitungsaufwand.
Die gepackten Codierungsregeln definieren auch einen eingeschränkten Satz von Codierungsregeln, CANONICAL-PER der nur eine einzige mögliche Codierung für eine gegebene Datenstruktur erzeugen soll. Die Rolle von CANONICAL-PER ähnelt daher der Rolle von DER oder CER.
Octet Encoding Rules [ edit ]
Die Octet Encoding Rules (OER) waren so konzipiert, dass sie einfacher zu implementieren sind und Codierungen kompakter als die produzierten produzieren von den Basic Encoding Rules (BER). Neben der Reduzierung des Entwicklungsaufwands von Encodern / Decodern kann die Verwendung von OER die Bandbreitennutzung verringern (wenn auch nicht so sehr wie die Regeln der gepackten Codierung), CPU-Zyklen einsparen und die Latenzzeit für Codierung / Decodierung verringern.
JSON-Kodierungsregeln [ edit ]
Die ITU-T standardisiert [15] die neuen JSON-Kodierungsregeln (JER) in denen angegeben wird, wie kodiert werden soll ASN.1-Abstract-Werte in JSON, sodass die resultierenden Kodierungen von jedem JSON-Reader gelesen werden können. Wenn ein vorhandenes ASN.1-Schema mit JER verwendet wird, wird eine Standard-JER-Codierung erstellt. Der Autor des ASN.1-Schemas kann jedoch auch die Struktur der JER-Codierungen durch Hinzufügen der JER-Codierung auf bestimmte Weise ändern Anweisungen im Schema. Dadurch kann ASN.1 als Schemasprache für JSON verwendet werden.
Beispiel [ edit ]
Dies ist ein Beispiel für ein ASN.1-Modul, das die Nachrichten (Datenstrukturen) eines fiktiven Foo-Protokolls definiert:
FooProtocol DEFINITIONEN :: = BEGINN FooQuestion :: = SEQUENCE { trackingNumber INTEGER, Frage IA5String } FooAnswer :: = SEQUENCE { questionNumber INTEGER, antworte BOOLEAN } END Dies könnte eine Spezifikation sein, die von den Erstellern des Foo-Protokolls veröffentlicht wurde. Konversationsflüsse, Transaktionswechsel und Status werden nicht in ASN.1 definiert, sondern werden anderen Schreibweisen und Textbeschreibungen des Protokolls überlassen.
Wenn eine Nachricht angenommen wird, die dem Foo-Protokoll entspricht und an die empfangende Partei gesendet wird, ist diese Nachricht (Protokolldateneinheit (PDU)):
myQuestion FooQuestion :: = SEQUENCE { TrackingNumber 5, Frage "Jemand da?" } ASN.1 unterstützt Einschränkungen für Werte und Größen sowie die Erweiterbarkeit. Die obige Spezifikation kann in geändert werden
FooProtocol DEFINITIONEN :: = BEGINN FooQuestion :: = SEQUENCE { trackingNumber INTEGER (0..199), Frage IA5String } FooAnswer :: = SEQUENCE { questionNumber INTEGER (10..20), antworte BOOLEAN } FooHistory :: = SEQUENCE { Fragen SEQUENZ (GRÖSSE (0..10)) VON FooQuestion, Antworten SEQUENCE (SIZE (1..10)) VON FooAnswer, eine Abfolge (Größe (100)) von Integer (0..1000), ... } END Durch diese Änderung wird für trackingNumbers ein Wert zwischen 0 und einschließlich 199 und für fragennummern ein Wert zwischen 10 und einschließlich 20 festgelegt. Die Größe des Fragen-Arrays kann zwischen 0 und 10 Elementen liegen, das Antwort-Array zwischen 1 und 10 Elementen. Das anArray-Feld ist ein 100-Element-Array mit Ganzzahlen fester Länge, das im Bereich von 0 bis 1000 liegen muss. Die Erweiterungsmarkierung '...' bedeutet, dass die FooHistory-Nachrichtenspezifikation in zukünftigen Versionen der Spezifikation zusätzliche Felder enthalten kann. Systeme, die mit einer Version kompatibel sind, sollten Transaktionen von einer späteren Version empfangen und senden können, obwohl sie nur die in der früheren Version angegebenen Felder verarbeiten können. Gute ASN.1-Compiler generieren (in C, C ++, Java usw.) Quellcode, der automatisch prüft, ob Transaktionen unter diese Einschränkungen fallen. Transaktionen, die gegen die Einschränkungen verstoßen, dürfen nicht von der Anwendung akzeptiert oder präsentiert werden. Die Verwaltung von Einschränkungen in dieser Schicht vereinfacht die Protokollspezifikation erheblich, da die Anwendungen vor Verstößen gegen Beschränkungen geschützt werden, wodurch das Risiko und die Kosten reduziert werden.
Um die myQuestion-Nachricht über das Netzwerk zu senden, wird die Nachricht als eine Reihe von Bytes mit einer der Codierungsregeln serialisiert (kodiert). Die Foo-Protokollspezifikation sollte explizit einen Satz von Codierungsregeln benennen, die verwendet werden sollen, damit die Benutzer des Foo-Protokolls wissen, welche sie verwenden und erwarten sollen.
Beispiel codiert in DER [ edit ]
Nachfolgend ist die oben gezeigte Datenstruktur im DER-Format codiert (alle Zahlen sind hexadezimal):
30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
DER ist eine Typ-Längen-Wert-Codierung, sodass die obige Sequenz unter Bezugnahme auf den Standard interpretiert werden kann SEQUENCE, INTEGER und IA5String-Typen wie folgt:
30-Typ-Tag, das SEQUENCE anzeigt 13 - Länge in Oktetten mit folgendem Wert 02 - Tag, das INTEGER anzeigt 01 - Länge in Oktetten mit folgendem Wert 05 - Wert (5) 16 - Tag, das IA5String angibt (IA5 bedeutet den gesamten 7-Bit-ISO-646-Satz einschließlich Varianten, ist aber in der Regel US-ASCII) 0e - Länge in Bytes des folgenden Werts 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f - Wert ("Jemand dort?")
Beispiel in XER codiert [ edit ]
Alternativ ist es möglich, dieselbe ASN.1-Datenstruktur mit XML-Encoding-Regeln (XER) zu codieren, um eine bessere Lesbarkeit "zu erreichen das Kabel". Es würde dann als die folgenden 108 Oktette erscheinen (Anzahl der Leerzeichen schließt die Leerzeichen ein, die für den Einzug verwendet werden):
Beispiel in PER (nicht ausgerichtet) codiert [ edit ]
Alternativ dazu, wenn gepackte Codierungsregeln verwendet werden, die folgenden 122 Bits (16) Oktette belaufen sich auf 128 Bits, aber hier werden nur 122 Bits Informationen übertragen, und die letzten 6 Bits sind lediglich Auffüllen):
01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0
In diesem Format werden Typ-Tags für die erforderlichen Elemente nicht codiert, sodass sie nicht analysiert werden können, ohne die erwarteten Schemas zu kennen, die für die Codierung verwendet werden. Darüber hinaus werden die Bytes für den Wert des IA5String mit 7-Bit-Einheiten anstelle von 8-Bit-Einheiten gepackt, da der Encoder weiß, dass die Codierung eines IA5String-Bytewerts nur 7 Bit erfordert. Die Längenbytes werden hier jedoch auch für das erste Integer-Tag 01 codiert (ein PER-Packer könnte sie jedoch auch weglassen, wenn er weiß, dass der zulässige Wertebereich auf 8 Bit passt, und das Einzelwertbyte 05 sogar mit weniger komprimieren kann als 8 Bit, wenn bekannt ist, dass zulässige Werte nur in einen kleineren Bereich passen).
Beachten Sie auch, dass die letzten 6 Bits in der codierten PER in den 6 niedrigstwertigen Bits des letzten Bytes c0 mit Nullbits aufgefüllt werden: Diese zusätzlichen Bits werden möglicherweise nicht übertragen oder zur Codierung anderer Daten verwendet, wenn diese Sequenz als eingefügt wird ein Teil einer längeren nicht ausgerichteten PER-Sequenz.
Dies bedeutet, dass nicht abgeglichene PER-Daten im Wesentlichen ein geordneter Bitstrom sind und kein geordneter Bytestrom wie bei ausgerichteten PER, und dass die Dekodierung durch Software auf üblichen Prozessoren etwas komplizierter sein wird, da dies zusätzliche erfordert kontextuelles Bit-Shifting und Masking und keine direkte Byteadressierung (die gleiche Bemerkung würde jedoch bei modernen Prozessoren und Speicher / Speichereinheiten zutreffen, deren kleinste adressierbare Einheit größer als 1 Oktett ist). Moderne Prozessoren und Signalprozessoren enthalten jedoch Hardwareunterstützung für die schnelle interne Dekodierung von Bitströmen mit automatischer Handhabung von Recheneinheiten, die die Grenzen adressierbarer Speichereinheiten überschreiten (dies ist für die effiziente Verarbeitung in Datencodecs für die Komprimierung / Dekomprimierung oder mit einigen Verschlüsselungen erforderlich). Entschlüsselungsalgorithmen).
Wenn eine Ausrichtung an Oktettgrenzen erforderlich wäre, würde ein ausgerichteter PER-Codierer Folgendes erzeugen:
01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
(in diesem Fall wird jedes Oktett einzeln mit Null-Bits an den nicht verwendeten höchstwertigen Bits aufgefüllt).
Die meisten Tools, die ASN.1 unterstützen, haben folgende Funktionen:
- analysiert die ASN.1-Dateien,
- generiert die entsprechende Deklaration in einer Programmiersprache (wie C oder C ++),
- generiert die Kodierungs- und Dekodierungsfunktionen auf der Grundlage der vorherigen Deklarationen.
Eine Liste von Tools ASN.1 mit Unterstützung finden Sie auf der ITU-T Tool-Webseite.
Vergleich mit ähnlichen Schemata [ edit ]
ASN.1 ist in Zweck und Verwendung ähnlich wie Protokollpuffer und Apache Thrift, die auch Schnittstellenbeschreibungssprachen für die plattformübergreifende Datenserialisierung sind . Wie diese Sprachen verfügt es über ein Schema (in ASN.1, das als "Modul" bezeichnet wird) und eine Reihe von Codierungen, typischerweise Typlängenwertcodierungen. ASN.1, 1984 definiert, liegt jedoch viele Jahre vor ihnen. Es enthält auch eine größere Auswahl grundlegender Datentypen, von denen einige veraltet sind, und bietet mehr Optionen für die Erweiterbarkeit. Eine einzelne ASN.1-Nachricht kann Daten aus mehreren Modulen enthalten, die in mehreren Standards definiert sind. ASN.1 enthält auch eine integrierte Unterstützung für die Einschränkung von Werten. Ein Modul kann beispielsweise ein ganzzahliges Feld angeben, das im Bereich von 0 bis 100 liegen muss.
ASN.1 ähnelt visuell der erweiterten Backus-Naur-Form (ABNF), mit der viele Internetprotokolle wie HTTP und SMTP definiert werden. In der Praxis sind sie jedoch recht unterschiedlich: ASN.1 definiert eine Datenstruktur, die auf verschiedene Arten codiert werden kann (z. B. JSON, XML, Binär). ABNF hingegen definiert die Kodierung ("Syntax") und definiert gleichzeitig die Datenstruktur ("Semantik"). ABNF wird tendenziell häufiger zum Definieren von für den Menschen lesbaren textuellen Protokollen verwendet und wird im Allgemeinen nicht zum Definieren von Typlängenwertkodierungen verwendet.
Viele Programmiersprachen definieren sprachspezifische Serialisierungsformate. Zum Beispiel das "Pickle" -Modul von Python und das "Marshal" -Modul von Ruby. Diese Formate sind im Allgemeinen sprachspezifisch. Sie benötigen auch kein Schema, wodurch sie einfacher in Ad-hoc-Speicherszenarien verwendet werden können, jedoch für Kommunikationsprotokolle ungeeignet.
Für JSON und XML ist ebenfalls kein Schema erforderlich, sodass sie einfach zu verwenden sind. Bei beiden handelt es sich jedoch um plattformübergreifende Standards, die insbesondere bei der Kombination mit einem XML-Schema oder JSON-Schema für Kommunikationsprotokolle weit verbreitet sind.
Weitere Einzelheiten finden Sie unter Vergleich der Datenserialisierungsformate.
No comments:
Post a Comment