PINCode的意义

考虑下支付pin code的意义.

如果没有pin code而协议走的是对称加密的话.
那么理论上只要能够对process/device有一定的访问权限的话,reveal key应该不是什么问题.

而https的话,机制上也有可能通过root certificate的方式让加密透明化.

剩下私有的非对称加密方式.

原则上来说,因为对于client的发出的信息来说,只有key owner能够decrypt.
所以貌似没什么问题.

但这里有一点是,key owner其实并不能verified client.
因为它verify的是基于public key的一个signature.
只是某种integrity的校验,而对于消息的发起者身份也是没有任何信息的.

于是,理论上,在client和owner之间就存在一个中间人的机会.
这样的话,同样可以使得加密透明化.

而如果需要对client和owner做一个第三方认证,也就是类似https方式的话,同样地不能避免中间人攻击.

所以,实际上来说,这里的问题一个消息的integrity.
另一个是authorization.

而integrity是建立在authorization之上的.
因为不管你的integrity check多么完善.
如果不能确认消息的制造者是期望中的一样的话,也是没有意义的.

那么怎么做authorization呢?

或者直观的一个例子就是,如果确认一个communication channel另一端的你是你.
而不是一条狗.

然后看pin code.

假设pin code没有leak的话.
或者说pin code是只有client和service provider之间才知道的信息的话.
换句话说,就是没有第三方知道这个信息的话,也就没有authorization的问题.

因为能通过这个pin code关联起来的除了自身就是对方.

本质上来说,这里依赖的是某种形式two party private information.

所以它的问题在于,如果leak了呢.

考虑什么时候会leak.

一个是在首次交换的时候.
或者说存在一个唯一一次交换信息过程的时候.

比如设定pin code让对方知道/确认的形式.

这个时候因为没有一个private information,所以理论上是存在leak的机会的.

那么存在不存在不需要交换,但双方都能agree的一个形式呢?

理论上是可以存在的.

一个最简单的方式就是考虑类似btc的方式.
双方随机生产一个code,然后encrypt一个公共信息,然后尝试decrypt这个信息.
如果能够成功还原,那么就因为这双方有了一个agreement.

这样的话,剩下的问题就是如何提高这种碰撞/配对的成功概率.

理论上可以把生产算法narrow到跟时间设备信息等已知条件习惯的某种半确定性算法.
比如最简单的通过当前通信的ip:port+limited random field去尝试配对.

当然,这里同样存在中间人的问题.
因为一开始谁也不知道谁是谁.

所以同样存在一个开始negotiate的时候被中间人的机会.

这样的话,倒不如回退回直接交换pin code的方式.

再扩展一下考虑用户名密码的模式的话也是类似.

本质上来说,这里需要的是一个private held的information.
用来做unique identity和mutual information.

于是,这里再回头看https的话,其实算不错的方案了.

通过https交换最初的pin code.
不存储的话,以后即使信道被compromise.
只要这个code保存地好/没有leak,那大致上还是能够做身份确认的.