EMMC 5.1 https://www.doc88.com/p-33573167852277.html

HMAC-SHA: https://dl.acm.org/doi/pdf/10.17487/RFC4634

SHA: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

https://www.cnblogs.com/foxclever/p/8593072.html

https://blog.csdn.net/qq_32907491/article/details/131524420

https://blog.csdn.net/Thanksgining/article/details/111315721

https://blog.51cto.com/u_15127595/3381488

https://www.doc88.com/p-4983979995950.html

RPMB在EMMC 5.1协议里面主要规定了其帧格式（每一帧512B数据，有效数据为284B），hmac计算使用的算法hmac-sha256. 操作flow主要包括认证密钥编程，该过程须在安全环境下进行，例如生产环境；认证数据读，认证数据写，认证设备读，认证设备写，这五个主要的flow。RPMB空间是以128KB为单位的独立空间，起始地址为0。认证设备读写的地址空间只有2个256B。RPMB支持1帧，2帧，32帧的数据验证。

根据以上信息，是不难设计出RPMB协议所要求的HMAC-SHA算法的。HMAC-SHA算法可以根据协议文档直接写出。但能够使用起来比较顺利的，还需要考虑一下几个问题：

1.如果客户要求支持SM3，则HMAC-SHA256需要内嵌一个SM3算法实现，其实SM3与SHA256非常相似，都是哈希压缩算法的一种，有一点明显的区别在于SM3实现相较与SHA256实现需要多生成4个DW，这在RTL上表现为多用4个cycle时间，当然也可以靠展开的方式抹平这4个cycle的差距，而这需要面积及速度方面的牺牲。

2.对于FW使用友好的支持。由于RPMB对帧数据的要求，加上HMAC-SHA256计算时需要数据的连续存放。针对host发送超过32帧RPMB数据（违法协议）时，如果HMAC-SHA256不支持多帧计算暂停再计算的功能，可能dbuf没那么大连续空间一次把数据存储完毕供HMAC-SHA256计算使用。对于dbuf空间的利用上，FW有一套自己的管理办法。在进行32帧数据计算时，也可能存在没有足够存放数据的连续空间，需要HMAC-SHA256支持计算完一部分帧之后，等FW更新剩余部分数据帧，再开始计算。