Day26 - [丰收款] 永丰线上收款支付API功能实作总结(2)

在前半段的系列文章，我们把视野缩的很小，一篇一篇着重在每日赶进度的技术细节，看看怎麽使用Python来实作出规格书中的每一个功能，验证每一个步骤的正确性。

现在有机会重新用较宽广的视角来重新审视这些实作过程的技术环节，可以怎麽思考与运用。

前一篇我们分析了使用者情境，以及丰收款的服务范围，技术与环境的选用。在确保了读文章的你，有几个符合条件的可能性，不会浪费时间：

1. 你本身具备开发能力，或者可以听懂开发技术 (例如你可以找外包来写)
2. 需要永丰API的线上收付款服务
3. 或者即使你不直接使用永丰API，但单纯想了解线上金流的概念或技术实作
4. 即使换成了其他语言或框架你也可以驾驭

以上第三点我觉得其实蛮重要的，因为其实在没有接触过「线上金流技术」这一块(我指的仅是「使用服务」，不是当无类似永丰API端的角色)，先不管到底用的是不是永丰金的服务，很少人有把握知道自己的网站若缺少了金流服务，到底可以怎麽做，串不串的地来，心中自然都会感觉到金流的处理很困难，只觉得那是一片黑盒子，往往想了解但不得其门而入。

就算有机会和提供金流服务的公司取得资料，也只有很生硬的规格书供阅读，而没有比较具有教学性质或者分享性质具「人味儿」的文章让自己参考。这是iThome铁人赛这次主题我认为相当有意义，至少有机会藉由这个活动产出了不少的文章，提供未来想了解的读者有完整系列文可参考。

重新盘点技术关键点

在写完了一系列的文章，其实每天写有关永丰金API文章的过程，有绝大半的时间都是花在反覆实作与发现问题解决问题，我个人的理念是希望每一篇写作几乎都是希望在当天发表的文章就是「正确实作後的内容分享」，尽可能不要以边卡住边撰写的方式提供可能误导的讯息给读者。所以真正花时间的不在撰文本身而已，而是要花相当多时间试误与解决问题。

这边就把过去这些日子对於永丰API实作技术面的关键点整理一下，而且这个部份必须是全部走完实作後，再来写才可看的到全貌之处。

整理一下单向发送API到永丰接收的流程全貌

API讯息服务

在上图中我们可以看到几个我们实作的关键点，由於最左侧的原始明文的产生，是和不同的讯息内容有关。再复习一下，这里的讯息内容，简单一点来说，就是依不同的功能所需要和永丰API提出的功能服务，而因为永丰API把这样的功能称之前「讯息」，因此无论是要「建立一篇订单 (但内含了需要不同的付款方式)」或是「查询某个付款状态」，对API叫用而言都是一则「讯息」。

所以有关服务讯息的部份，在你的商业逻辑是要和中间的资安处理流程拆开来。

简单说，你会需要依服务功能拆成：

1. 建立订单，但需使用ATM付款
2. 建立订单，但需使用信用卡付款
3. 取得PayToken
4. 拿PayToken去问回付款结果
5. 以订单条件询问付款结果

而上面这边的服务，因为有绝大部份会使用相同的「讯息内容」JSON格式，所以可再进行共同部份的重构拆解。

有关资安处理流程

把上面这边先准备好後，接着就是「无论哪一种讯息服务都需要的资安处理流程」，设计要点，请务必从左侧的服务商业逻辑中独立出来！

如同我先前说的，虽然规格书是先讲Sign安全签章，再讲AES Message加密，但我始终不认为是这个顺序。我觉得以资安的意义来说，你要先知道怎麽把你手上的明文加密成密文，接下来才谈收到密文的人，除了把密文解开後，再来谈「怎麽确保这是加密者的原始未遭篡改不可否认的内容」。当然两者就「技术面」而言，是平行不分顺序的，但我认为「意义上」是有顺序的。

如果你只看到「传送端」这一块，自然觉得先加密Message再算Sign还是相反过来，好像都一样，但如果我们把右边「永丰API接收讯息」也考虑进去，就会知道「必须要先解密」，拿的到明文，才能进行「Sign的重新运算与产生」，然後拿运算结果去比对收到的Sign是否一样。

因此，我们先看API传送端的逻辑，上面的图只看到我们需要处理「AES加密」和「产生安全签章」的处理流程，但如果看完右侧永丰收到我们的加密讯息後要多做「AES解密」以及「比对签章」。因此这部份我们也需要一并加在我们的流程里面，原因是讯息是一去一回的，所以我们建立订单後，永丰API需要回覆我们ATM虚拟帐户或者信用卡刷卡网址，永丰回传给我们的内容，也会比照我们传出的方式进行加密与附上安全签章。我们的角色就会反转过来，如同右上角的图一样，需要进行一连串的安全处理流程，

所以这边再加上「AES解密」以及「比对签章」，如图用红框所示。

资安防护的关键点

那接着我想谈一下在这过程中，哪些点是为提升资安而加强防护的部份。

盘点有关资安相关的重要因子，整个高度资安防护是由以下综合建构而来

1. HashID：由4组Hash代码产生得固定值，作为AES Key加密对称金钥用途。(需注意人为保密)
2. Nonce值：每次询问，用完即丢，1分钟时效。 (高动态具时效性)
3. IV值：加解密固定的对称金钥时会搭配使用才能正确加解密，基础是由每次变动的Nonce而来 (高动态具时效性)
   前三项主要使用AES-CBC作加密产生密文
4. Sign的产生：
   • 以「永丰自定的取舍规则」产生内文杂凑 (取得规格书者就知道，有一点半公开的密秘)
   • 加上HashID (固定值，需作到人为保护)
   • 加上Nonce值 (高动态具时效性) --> 这是我认为相当重要的关键，因为其他点都是固定不变的或自订规则。
   • 整个再做SHA256 (产生数位签章，看起来是无法阅读的代码，但他是可逆的，不是加密法！)
5. 整个传输过程需符合HTTPS TLS 1.2
6. Nonce的取得来源的IP需要相同 (永丰API端会纪录)

安全保护力解析

因此在双方API交换资料的过程中，基本上符合以下资讯流程：

1. 传属通道本身已加密(TLS 1.2)
2. 若不慎被有心人事截取封包，且被解开了 → 讯息本身是以AES加密的
3. 若固定的AES Key (HashId)在人为保护疏失下已被有心人士取得，那麽要解开AES就有非技术性的风险存在
4. 但是要解密AES过程，是需要输入初始向量IV值 (由Nonce而来)，已大大提高被破解风险
5. 若是能在一分钟之内破解 (现在的风险为内容遭不合法方式检视)，但至少要防止被资料篡改，因此这个一分钟就失效且一次性的Nonce就发挥了高度的作用。
6. 如果真的被破解，而且也被尝试的要进行资料修改再送出，但还有一个重要的安全签章Sign作比对
7. 安全签章里面有一些规则是永丰自己定义的，要取得规格书的人至少才知道不是只是拿原讯息内文JSON直接作SHA256杂凑这麽简单，还包含了属性排序、某些多值栏位不放入、将JSON格式转为类似URL Parameters的Key-Value串接。不过，以自订义双方内部规则作为安全防护，个人觉得是很有限度的防护方式。基本上就是只要规则被知道就无防护力了。
8. Nonce的IP的要求来源是会在永丰端记录，这个机制的防护规则是能防外贼但防不了内鬼。

由上面这一些分析，可以了解同样是API的呼叫，若对於资安要求没那麽高的服务，基本上不会使用这麽全面的规则与流程，但也由於我们公开透明的研究完这些实作细节，可以了解到要和永丰作一次API处理，是相当高度安全的，也由此来让系统对接用户，以及终端使用用户(如果他们真的有机会了解到的话)都可以放心的作资料交换。