【问题标题】:Can ASN.1 support putting field lengths in a different place?ASN.1 可以支持将字段长度放在不同的位置吗?
【发布时间】:2018-06-16 07:00:20
【问题描述】:

我有一个协议,其在线格式已定义,我想使用 ASN.1 对其进行编码/解码,但它似乎破坏了定义的 BER/DER/PER 选项。无论出于何种原因,协议开发人员没有将有效负载大小/长度直接放在有效负载本身之前 - 所以我不能使用自动 BER/DER。但是由于有效载荷可以是可变长度的,所以我也不能使用 PER。这是一个例子:

     12'b           12'b       4'b     4'b   
|------------|--------------|-------|------|
| some stuff | payload size | blah2 | blah |    Header
|------------------------------------------|
|              payload word 1              |
|------------------------------------------|
|                    ...                   |    Payload
|------------------------------------------|
|              payload word N              |
|------------------------------------------|
| much stuff | many bits | such doge | wow |    Trailer
|------------------------------------------|

所以这里可能有两个问题:

  1. 有没有办法使用其中一种 ASN.1 编码来指定某些字段作为后面字段的长度 - 所以您可以说位 9-20 包含位 33-N*32 的长度,但是您'正在跳过可能包含其他不相关垃圾的第 21-32 位?
  2. 我可以看到如何编写算法/规则来支持上述内容,所以如果目前无法使用 ASN.1 执行此操作,是否有方法(和文档)来编写新的对现有编码的某种规则或扩展?

编辑

为了澄清我为什么要提出 ASN.1,而不重复 a previous question,是因为它几乎正是我正在寻找的东西 - 只是显然没有办法处理我在这里询问的特定用例.我需要反序列化现有的二进制协议,我不想自己编写,因为已经有很多 tools 声称他们可以做某种形式的这种事情。如果有人有其他建议,我很乐意尝试。

【问题讨论】:

  • 从显示的示例中,似乎很难找到从编码到 ASN.1 抽象值的映射,反之亦然。那么问题来了,你为什么要使用 ASN.1?
  • ASN.1 位于表示级别,与您自己的协议规范无关。我同意@Henry,目前尚不清楚您在这里查看 ASN 的原因。
  • @Crypt32 我看不出 OSI 模型与我的问题有什么关系,无论如何这不一定是真的。 ASN.1 可用于序列化和反序列化二进制数据,无论它是什么“层”。我只是问是否有办法将它用于我正在处理的数据包格式。欢迎使用替代品。

标签: asn.1 tlv


【解决方案1】:

ASN.1 标准文档之一指定了称为编码控制符号 (ECN) 的内容。其目的是使使用 ASN.1 加上 ECN 来处理非 ASN.1 消息成为可能。它可能会满足您的需求。但是,我会警告您,使用它非常复杂,而且我只看到一家公司声称支持它(我不知道他们的支持有多完善)。

【讨论】:

  • 是的,ECN 能够处理编码中长度字段的这种重新排列。然而,它相当复杂,并且可能需要商业工具来实施。我碰巧在一家创建 ECN 工具的公司工作。
【解决方案2】:

我相信您无法更改 BER/DER/CER 序列化中长度字段的位置——它只能出现在有效负载之前,或者它可以只是构建有效负载的一对哨兵(例如,无限长度编码)。

不过,您的最终目标还不是很清楚。为什么需要 ASN.1?

【讨论】:

  • 最终目标是能够为在我的示例中定义的二进制数据生成反序列化器。 ASN.1 不是必需的,但它是我发现的最接近的 - 当数据没有可变长度字段时,解码效果很好。
【解决方案3】:

我认为您可能稍微误解了 ASN.1 的目标 - BER/DER/CER 编码在某种程度上是 ASN.1 的辅助,尽管它们可能是其中最知名的部分。

ASN.1 是一种指定 abstract 语法的方式:它是一种表达方式,例如“消息类型 13 是任意长度的整数字符串对序列”,而无需说明如何表示消息。因此,它是系统规范的一部分,因此与其他更晚的方法(如 UML)实际上处于 IT 思维空间的同一部分。来自X.680的总结部分:

只要需要定义信息的抽象语法,就可以应用 ASN.1 符号,而不会以任何方式限制信息的编码方式以进行传输。

重点在于抽象语法。

“编码规则”是这种语法的具体实现,在单独的标准X.690 中定义,其总结为:

此建议 |国际标准定义了一组基本编码规则 (BER),可以应用于使用 ASN.1 表示法定义的类型的值。这些编码规则的应用为这些值生成了传输语法。 [强调我的]

换句话说,编码规则是如何传输使用 X.680 语法定义的消息的一个示例,但它们并不是唯一的方法。我认为最初期望使用这两个标准的方式是,您开发或接收用 ASN.1 语法编写的规范,然后使用“ASN.1 编译器”将其转换为一些代码可以序列化和反序列化该特定语法。 (尽管如此,我猜想分布最广的 DER 解析器,即那些用于 X.509 证书的解析器,通常是自定义编写的,而不是以这种方式派生的)。

我所说的“示例”是指标准是说“如果您没有特别的理由选择另一种传输语法,这里有一个您可能会考虑的预先指定的语法”。

这意味着 BER/DER/CER/PER 编码并非旨在作为一种完全通用的方式来传输二进制数据,或作为一种表达随机线格式结构的方式,因此它们并非旨在可以按照您的问题建议的方式进行扩展。

或者,如果您正在处理的线路格式的设计者已经做出了与 BER 编码设计者相同的决定,即为格式,那么您可能已经对其进行了逆向工程 ASN.1 规范,因此使用 ASN.1 编译器生成(反)序列化器(万岁,问题解决了,早点喝啤酒!)。

但看起来他们没有,所以你无法解读那个鸡蛋,我认为你被困在为你的有线格式手动编写一个(反)序列化器。这意味着(万岁?)您要解决一个有趣但又独立的问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-11-18
    • 1970-01-01
    • 2020-07-24
    • 1970-01-01
    • 1970-01-01
    • 2014-04-12
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多