العلامات غير المعلنة في المدخلات إلى وحدة فك ترميز ASN.1

Question

لدي مواصفات لبناء بناء جملة ASN.1 أرغب في تعديله عن طريق إضافة بعض الحقول. إذا قمت بإنشاء سلسلة مشفرة باستخدام BER مع الحقول الجديدة ثم حاول فك تشفير هذه السلسلة باستخدام وحدة فك ترميز لا تعرف هذه الحقول الإضافية ، فما الذي يجب أن تكون النتيجة؟ هل ستفشل فك التشفير لأن هناك حقول لا يتعرف عليها وحدة فك الترميز؟ هل ستفكك وحدة فك ترميز الحقول التي يمكن أن تتعرف عليها وتجاهلها تمامًا؟ هل هذه قضية تنفيذ فك التشفير تمامًا ، لذا فإن أي من النتيجة ممكنة ، اعتمادًا على كيفية تنفيذ وحدة فك الترميز؟

في الوقت الحالي ، أستخدم برنامج التحويل البرمجي/وحدة فك الترميز مفتوح المصدر ASN.1 ويبدو أنه يفشل تمامًا ، لكنني لست متأكدًا مما إذا كان هذا بسبب التنفيذ أو لأن قواعد ASN.1 تملي هذا النوع من النتائج؟

Answer 1

بالتأكيد لا يعتمد على التنفيذ. أي إذا كانت تطبيقات مختلفة تتعامل معها بشكل مختلف ، فإن أحدها يفعل ذلك بشكل غير صحيح. إذا ذهبت إلى فك تشفير حقول غير معروفة باستخدام وحدة فك ترميز لا تتوقع حقول غير معروفة ، فيجب أن تفشل فك التشفير. لن يتخطى حقول غير معروفة.

ومع ذلك ، هناك طريقة لتوفير حقول إضافية حتى قبل معروفة. هو لاستخدام علامة التمديد ("..."). دعنا نقول أننا نطور إصدارات مختلفة من مواصفات ASN.1. دعنا نسميهم V1 و V2 و V3 ، إلخ. V1 هو المواصفات الأصلية ، لكننا نفهم في الوقت الذي نخيم فيه V1 أنه من المحتمل أن يتعين علينا تعديله في مرحلة ما. للسماح بذلك ، بدلاً من شيء مثل

Z ::= SEQUENCE { a INTEGER,
                 b OCTET STRING,
                 c Message1
}

سوف نعلن أن z قابلة للتمديد مثل هذا

Z ::= SEQUENCE { a INTEGER,
                 b OCTET STRING,
                 c Message1,
                 ...
}

تقول علامة التمديد أنه ، بعد C ، قد يكون هناك المزيد من الحقول غير المعروفة بعد. يجب أن يعالج وحدة فك الترميز الرسائل التي تحتوي على مثل هذه الحقول ، طالما أنها تتبع C ، على أنها صالحة. لن يتمكن وحدة فك الترميز من فك تشفيرها لأنه لا يعرف ما الذي ينبغي أن يكون ، لكنه يعلم أنها مسموح بها.

دعنا نقول أننا نقوم بتحديث V1 إلى V2 عن طريق إدخال حقلين جديدين مثل هذا إلى حد ما

Z ::= SEQUENCE { a INTEGER,            -- V1
                 b OCTET STRING,       -- V1
                 c Message1,           -- V1
                 ...,
             [[  d PrintableString,    -- V2
                 e BOOLEAN          ]] -- V2
}

في هذه الحالة ، يمكن أن يتداخل إصدار V1 مع إصدار V2. لن يتضمن مشفر V1 D أو E ، في حين أن تشفير V2 سيشملها. من وجهة نظر وحدة فك الترميز ، فإن وحدة فك ترميز V1 تقبل (ولكن لا فك تشفير) D و E ، في حين أن وحدة فك ترميز V2 سوف تفكك D و E إذا تم العثور عليها. لذا فإن وحدة فك ترميز V1 تقبل كل من ترميزات V1 و V2 ، متجاهلة D و E كلما وجدت ؛ سيقبل وحدة فك ترميز V2 أيضًا ترميزات V1 و V2 ، مع الإشارة إلى أن ترميز V1 لن يتضمن D أو E ، لكنه يظل صالحًا.

يمكننا مواصلة هذا من خلال الإصدارات الإضافية ، على سبيل المثال ،

Z ::= SEQUENCE { a INTEGER,            -- V1
                 b OCTET STRING,       -- V1
                 c Message1,           -- V1
                 ...,
             [[  d PrintableString,    -- V2
                 e BOOLEAN         ]], -- V2
             [[  f PrintableString,    -- V3
                 g ExtensionMessage]]  -- V3
}

حيث يمكن أن يتداخل V1 و V2 و V3.

لاحظ ، مع ذلك ، أنه نظرًا لأننا نتعامل مع تسلسل ، يجب الحفاظ على الطلب. لا يمكن أن يكون لديك e بدون d ، ولا g بدون d ، e ، و f.

الاستنتاج هو أنه إذا كان تعريف النوع الخاص بك يتضمن علامات تمديد ، فيمكنك إضافة حقول جديدة ، ولكن إذا لم يحدث ذلك ، فقد لا تكون كذلك.

Answer 2

كل هذا سوف يعتمد على المواصفات والتنفيذ. باختصار - لا توجد طريقة لتقول. الأمر متروك للتنفيذ. بعض المواصفات لأي بروتوكول/تنسيق معين باستخدام ASN.1 سوف تنص صراحة على أنه يجب تجاهل عناصر غير معروفة ، وفي هذه الحالة لا ينبغي أن تفشل فك التشفير.

والأكثر شيوعًا ، سترفض وحدة فك الترميز أي مدخلات لا تتوافق تمامًا مع بناء جملة ASN.1 الذي من المفترض أن يتم فك تشفيره.