詹天佐

整理了一下CCC组织的汽车数字钥匙Release 3中关于车主配对Owner Paring，过程的APDU指令和数据说明。基本可以算是在车端的角度进行车主配对操作。里面的章节表格编号，都按照CCC数字钥匙Release 3文档中的编号走，方便将来检索对照。

0x01 概述使用electron开进行桌面程序的开发，似乎成了WEB前端开发人员转桌面程序开发的首选。近期有一些使用在electron中使用加密锁的需求，学习了一下在Node.js中通过ffi-napi模块调用动态链接库，把几款加密锁产品的动态库使用javascript封装了一下，实现了electron中使用加密锁功能。开发过程中遇到了一些问题，踩了一些坑，这里总结记录一下。这里使用接口函数参数类型比较复杂的ROCKEY-ARM的动态链接库来进行开发。NOTE: javascript封装的ROCK

使用中国剩余定理CRT对RSA运算进行加速。

中国剩余定理 高斯算法 低加密指数广播攻击

在对数据进行加解密,签名,计算MAC的时候,有时需要对数据进行填充,填充的方法主要分为两大类,一种是比特填充(Bit Padding),填充时以比特为最小单位进行填充,另一种是字节填充(Byte Padding),填充时以字节为最小单位进行填充.当然有时候我们按字节处理数据时,一些比特填充和字节填充的效果是一样,比如ISO/IEC 9797-1 Padding Method 2和ISO/IEC 7816-4,数据如果最小处理单位都是字节的话,填充的效果其实是一样的.PKCS #1中定义的RSA算法用的P

网上有大量的基于OpenSSL实现的国密算法库，比如著名的GmSSL,可以直接拿来用。我自己常用的是mbedTLS的算法库，比较小巧简单，在mbedTLS的大数算法的基础上实现了国密SM2的签名和验签算法。在基于mbedTLS实现SM2签名和验签算法的过程中走过一些弯路，现在把实现的过程记录下来备忘。国密SM2算法也是基于椭圆曲线公钥算法，椭圆曲线上的运算都是和国际算法一样的，国密SM2规范中给出...

1.U2F 消息封包U2F协议是基于请求-响应方案的，当请求者发送一个请求消息到U2F设备中时，U2F会返回一个响应消息给请求者。在现在这一版的U2F协议中，消息的封包是基于ISO7816-4:2005 扩展APDU格式。请求消息封包的格式如下：CLA INS P1 P2 LC1 LC2 LC3 响应消息的格式如下： SW1 SW22.注册消息2.1注册消息 U

本来计划写U2F Raw Message的内容的，但是发现FIDO联盟在2015年5月份发布的最新的U2F规范中，增加了NFC协议，所以先写下NFC的协议吧。FIDO U2F NFC的协议其实非常简单，就是定义了一下FIDO U2F的AID和APDU的规范。1.协议简介FIDO客户端和认证设备之间通过NFC进行通讯，过程如下：（1）客户端发送选择applet指令（2）认证设备返

FIDO U2F认证，国内的文章一般翻译成FIDO两步认证。U2F是在现有的用户名+密码认证的基础之上，增加一个更安全的认证因子用于登录认证。用户可以像以前一样通过用户名和密码登录服务，服务会提示用户出示一个第二因子设备来进行认证。U2F可以使用简单的密码（比如4个数字的PIN）而不牺牲安全性。U2F出示第二因子的形式一般是按一下USB设备上的按键或者放入NFC。UAF先放一边，U2F的工作流程比较简单，具体的可以看FIDO联盟官网。下面主要说下U2F HID协议。首先要明确一下U2FHID协议不是

周末在家里用PCSC读卡器写了一个M1卡的工具，测试

招行银行的VISA芯片卡到手，虽说金融卡都差不多，但作为手里的第一张VISA智能借贷记卡片，还是简单测试了一下。拿到卡的时候手里只有一个接触卡读卡器，选择ADF后，卡片的相应中没有给出PDOL，没有PDOL的话，终端交易属性授权金额什么的就没法传进去了，没有PDOL的话就没有办法做电子现金交易了，按照VISA的规范，VISA的快速流程只能走非接触界面，接触界面不给PDOL是正常现象。找来一

继续前一张工行闪酷卡，其实当初已经测试完成之时忙着国庆回家，没有及时出测试报告，现在把其他项目的测试情况整理一下。接着上一篇，终端在GPO时送入的终端交易属性是22000000，表示终端不支持非接触式借记/贷记应用， 支持qPBOC，不支持接触式借记/贷记应用，终端具有联机能力，不支持联机PIN，不支持签名。1.GPOCommand:80A800002383212200000000

感谢@JulyClyde同学友情提供的工商银行闪酷钥匙扣，支持银联的闪付功能。卡片内的电子现金余额已经被圈提干净，余额应该是0。现在使用PC/SC的读卡器配合麻工强大的Snooper进行测试。首先选择PPSE.1.SELECTCommand:00A404000E 325041592E5359532E4444463031Response:6F2E840E325041592E53595

上一篇读记录的时候，对卡内数据解析不太熟悉，好多东西没有分析，今天重新学习规范对照分析一下，把不涉及本人隐私的内容也都发出来，方便分析。从上一篇的第10条指令重新来。10.READ RECORDAPDU:00B2010C3CRETURN:703A57136259****************************00000F9F6112313*3*3*30323139383

接上一篇，上次基本上卡在了选择ADF之后的操作，选择完ADF之后根据Response的数据，需要做获取处理选项GPO，但是对PDOL这个东西一直搞不明白，GPO指令的数据域是PDOL，PBOC规范上对GPO的指令写的也是很模糊，只说了没有PDOL的发8300，有PDOL项的发PDOL，但是泛泛的浏览PBOC规范，对选择应用之后返回的数据中PDOL的内容也没有细说，折腾了半天才反应过来PDOL的格式

之前没有对金融卡片研究过今天用自己的建行环球旅行信用卡学习一下。使用的读卡器是一款CCID的接触式读卡器，北京的中国移动营业厅有使用他的低版本型号。CCID的读卡器通讯API还算比较简单，自己之前有现成的代码，但是测试了一下，在选择完T0协议后，通讯还是有问题，向卡片发数还是有问题，总是犯0xE的错误。不查代码了直接用我司麻工研发的强大的snooper。首先上来是选择MF1.SELEC