畅链科技文档

简体中文

English

简体中文

English

外观

AS2 ​

AS2 由 IETF 于 2002 年制定，用以取代其在 1990 年代初期创建的 AS1。 由于零售业和快速消费品（FMCG）行业的主要参与者积极推动，AS2 在 2000 年代初期得到了迅速普及。沃尔玛是首家要求其供应商使用 AS2 协议、而非依赖拨号调制解调器进行商品订购的主要零售商。随后，亚马逊、Target、Lowe's、Bed Bath & Beyond 以及其他数千个品牌也纷纷跟进。许多其他行业同样采用了 AS2 协议，包括医疗保健行业，因为 AS2 符合法律层面的 HIPAA 合规要求。

技术概述 ​

AS2 规范定义于 RFC 4130，基于 HTTP 与 S/MIME。它是第二个开发的 AS 协议，并采用了与 IETF 在 1990 年代末期引入的原始 AS1 协议相同的签名、加密以及 MDN（按 RFC 3798 定义）约定。换句话说：

  • 文件会被编码为标准化的 S/MIME 消息（AS2 消息）中的“附件”。
    AS2 本身并不规定文件内容，通常采用另行约定的标准化格式，例如 XML 或 EDIFACT。
  • AS2 消息始终通过 HTTP 或 HTTPS 协议传输（HTTPS 隐含 SSL），通常使用 POST 方法（较少使用 GET）。
  • 消息 可以签名，但并非强制。
  • 消息 可以加密，但并非强制。
  • 在一切正常的情况下，消息可以请求返回 消息处理通知（MDN），但不要求必须请求。
  • 如果原始 AS2 消息请求了 MDN：
    • 在收到消息并成功解密或验证签名（如需要）后，会向原始发送方返回一个“成功”的 MDN。
      该 MDN 通常会被签名，但不会被加密（除非在传输过程中通过 HTTPS 临时加密）。
    • 原始发送方在收到并成功验证 MDN 上的签名后，将确认接收方已收到消息（这构成了 AS2 的不可否认性）。
  • 如果在接收或解析原始 AS2 消息时出现问题，可能会返回“失败”的 MDN。
    但 AS2 协议规定客户端必须将缺少 MDN 视为失败，因此部分 AS2 接收方在此情况下不会返回 MDN。
  • 与其他 AS 文件传输一样，AS2 通常要求通信双方在传输前交换 X.509 证书以及特定的交易伙伴名称。
    AS2 的交易伙伴名称通常可以是任何有效的短语。

MDN 选项 ​

与 AS1 或 AS3 文件传输不同，AS2 提供多种 MDN 返回方式，而非简单的“是 / 否”选项，具体包括：

AS2 + 同步 MDN ​

  • 通过 HTTP(S) 返回同步 MDN（又称 AS2 同步）
  • 使用与原始消息相同的 HTTP 连接返回 MDN
  • 优点：
    • 传输速度最快
    • 实时确认
  • 限制：
    • 不适合大文件
    • 低带宽环境下可能超时

AS2 + 异步（ASync）MDN ​

  • 通过 HTTP(S) 返回异步 MDN（又称 AS2 异步）
  • 使用不同的 HTTP 连接将 MDN 返回给发送方服务器
  • 常用于：
    • 大文件传输
    • 交易伙伴 AS2 服务器网络质量不佳的场景

AS2 + 电子邮件 MDN ​

  • 通过 电子邮件返回异步 MDN
  • 较少使用
  • 行为与 AS2 异步（HTTP） 类似，只是传输介质不同

AS2 无 MDN ​

  • 不返回 MDN
  • 行为与其他 AS 协议一致：
    接收方不会向发送方返回任何 MDN

文件名保留 ​

AS2 支持 文件名保留（Filename Preservation），用于将文件名传递给交易伙伴。
该功能在银行业尤为重要，因为业务流程通常依赖于文件名。

目前，AS2 厂商正在对文件名传递的实现进行认证，以确保其符合标准且具备互操作性。
在 AS2 测试中，可选择以下两种文件名保留配置：

  • 文件名保留，不要求 MDN 响应
  • 文件名保留，并对相关的 MDN 响应进行认证

沃尔玛建议联系 Drummond Group, LLC，以获取更多关于 EDIINT AS2 的信息，或索取可进行互操作性测试的 AS2 软件供应商名单。

安全性与加密机制 ​

AS2 的核心设计目标之一是提供 安全、可靠、可审计且具备不可否认性 的业务数据传输能力。其安全性主要依赖 S/MIME、PKI（X.509 证书）以及传输层安全机制 的组合实现。

加密（Encryption） ​

  • AS2 使用 S/MIME 对消息内容进行加密，属于消息级加密，与传输通道无关。
  • 加密过程采用 混合加密机制：
    • 使用对称加密算法（如 AES-128 / AES-256 或 3DES）对实际业务数据进行加密；
    • 再使用接收方的 X.509 公钥证书 对对称密钥进行加密。
  • 只有持有对应 私钥 的接收方才能解密消息内容，确保：
    • 数据机密性（Confidentiality）
    • 防止中间人或非授权方读取业务数据
  • AS2 是否启用加密由交易伙伴双方协商决定，但在生产环境中几乎总是强制启用。

数字签名（Digital Signature） ​

  • AS2 消息可使用发送方的 私钥进行数字签名。
  • 数字签名通常采用：
    • SHA-256 / SHA-1 作为摘要算法（现代实现推荐 SHA-256 及以上）
    • RSA 作为签名算法
  • 数字签名用于保证：
    • 数据完整性（Integrity）
    • 发送方身份真实性（Authentication）
    • 防篡改（Tamper Detection）

加密与签名顺序 ​

AS2 中通常采用以下处理顺序：

  1. 生成业务数据文件
  2. 对数据进行 签名
  3. 对已签名内容进行 加密
  4. 将结果封装为 S/MIME（CMS）消息
  5. 通过 HTTP / HTTPS 发送

该顺序确保接收方在解密后可以验证原始内容是否被篡改。

消息处理通知（MDN）的安全性 ​

  • MDN 本身也可以进行 数字签名，以防止伪造或篡改。
  • 成功 MDN：
    • 通常 必须签名
    • 绝不进行 S/MIME 加密（仅依赖 HTTPS 进行传输层保护）
  • 发送方在验证 MDN 签名成功后，可获得：
    • 接收确认
    • 消息成功处理的加密证据
    • 法律层面的不可否认性（Non-repudiation）

不可否认性（Non-repudiation） ​

AS2 的不可否认性由以下要素共同构成：

  • 发送方对原始消息的数字签名
  • 接收方对 MDN 的数字签名
  • 双方保存的：
    • 原始消息
    • MDN
    • 对应的证书与时间戳

这些信息可作为法律或审计证据，证明消息已成功发送并被接收方处理。

证书与密钥管理 ​

  • AS2 使用 X.509 公钥证书进行加密与签名。
  • 通常要求：
    • 每个交易伙伴至少维护一对证书（公钥 / 私钥）
    • 定期轮换证书（常见为 1–3 年）
  • 证书可以由：
    • 公共 CA（如 DigiCert、GlobalSign）
    • 私有 CA
    • 自签名证书
      生成（具体取决于交易伙伴要求）
  • 双方在正式通信前必须：
    • 交换公钥证书
    • 验证证书有效期、指纹与用途

传输层安全（HTTPS） ​

  • AS2 可运行于 HTTP 或 HTTPS 之上。
  • HTTPS 提供：
    • 传输过程中的临时加密
    • 防止流量嗅探与重放攻击
  • 即使启用 HTTPS，S/MIME 消息级加密仍然是 AS2 的核心安全机制，二者并不互斥。

安全最佳实践 ​

  • 强制启用：
    • 消息加密
    • 消息签名
    • MDN 签名
  • 使用 SHA-256 及以上 摘要算法
  • 使用 AES-256 作为对称加密算法
  • 定期轮换证书并提前测试证书更新
  • 保留完整的消息与 MDN 审计日志，以满足合规与取证需求