一、概述
JEDEC在2009年发布的eMMC V4.4规范JESD84-A44中首次引入RPMB机制，该机制使得eMMC具有一个特殊的数据安全分区，存储在该区域的数据，可实现认证保护和防重放保护，并且规范中也同步定义了操作指令和数据结构。RPMB分区的大小定义为128KB的整倍数（最大16MB），具体大小依赖各厂商自行设计。
二、RPMB机制介绍
2.1 RPMB机制概述
RPMB提供认证机制和防重放保护机制，主要通过Authentication Key和HMAC-SHA256算法、Write Counter、随机数机制实现。通过Authentication Key和HMAC-SHA256算法，在每次数据交互时额外计算1个MAC值，接受方通过校验该MAC值，检查数据是否是合法方发送以及数据是否被破坏。通过随机数和Write Counter确保不会遭受防重放攻击（防重放攻击：攻击者作为中间人，嗅探第一次交互的数据，并随后再次将此嗅探的数据发送给接收方。详细不在此处赘述）。
在正式介绍RPMB详细操作前，需介绍一些基础信息。初步了解如下的基础信息，才可以更容易理解RPMB操作。
2.1.1 Authentication Key
Authentication Key即HMAC算法使用到的密钥。当eMMC固件需要计算MAC值时，会读取该值，并进行MAC计算。该密钥特性如下：
-
- 密钥长度为32Bytes
-
- 该密钥存储在eMMC的OTP区域，故仅写入一次。
-
- 一旦写入成功，后续不能重写、不能擦除、不能被读取到eMMC外部（只能被eMMC固件读取）
2.1.2 Write Counter
Write Counter主要为实现防重放攻击。该值是一个自增的值，每当RPMB写入成功后，eMMC固件会将该值自增1。Write Counter长度为4Bytes，初始值为0x0000000000000000。当达到最大值（即0xFFFFFFFFFFFFFFFF）后，将不再自增，保持最大值不变，且Operation Result的bit[7]值置1。对eMMC外部程序来说，只能读取到该值，无法写入该值，该值的写入有eMMC固件负责。
2.1.3 RPMB操作数据结构
上图为RPMB特有的数据操作结构，相关字段含义如下
-
- Req/Resp：Request/Response Type，请求或响应类型。用于表明当前请求或响应的类型。长度为2字节
|--------|--------|------------------------|
| 类型 | 值 | 含义 |
| 请求类型标识 | 0x0001 | 请求写入Authentication Key |
| 请求类型标识 | 0x0002 | 请求读取Write Counter值 |
| 请求类型标识 | 0x0003 | 请求向RPMB写入数据 |
| 请求类型标识 | 0x0004 | 请求从RPMB读取数据 |
| 请求类型标识 | 0x0005 | 请求读取结果 |
| 响应类型标识 | 0x0100 | 响应写入Authentication Key |
| 响应类型标识 | 0x0200 | 响应读取Write Counter值 |
| 响应类型标识 | 0x0300 | 响应向RPMB写入数据 |
| 响应类型标识 | 0x0400 | 响应从RPMB读取数据 |
-
- Result：Operation Result，返回本次RPMB操作的结果，仅在响应中有效。长度为2字节。
| Bit[7] | Bit[6:0] |
|---|---|
| Write Counter状态（当Write Counter为最大值是，该bit置1） | Operation Result |
| 值 | 含义 |
|---|---|
| 0x00/0x80 | 操作成功 |
| 0x01/0x81 | 通用失败 |
| 0x02/0x82 | MAC失败（包括MAC不匹配，MAC计算失败） |
| 0x03/0x83 | Write Counter失败（包括Write Counter不匹配或自增失败） |
| 0x04/0x84 | 地址错误（包括地址不在正确范围、地址未对齐） |
| 0x05/0x85 | 写入失败 |
| 0x06/0x86 | 读取失败 |
| 0x07 | 未写入Authentication Key |
-
- Block Count：读写的块数（half sectors数量，一个half sectors为256Bytes）。长度为2字节。
-
- Address：本次读取或写入的数据地址
-
- Write Counter：写入计数值，详见2.1.2章节。
-
- Nonce：随机数。当数据结构用于请求时，由请求方生成随机数填充此处。eMMC处理后，将请求中的随机数copy一份放在响应的数据结构中
-
- Data：实际读写的数据，长度为256字节
-
- Key/MAC：Authentication Key或MAC值，长度为32字节。当请求为写入Authentication Key时，此处填充待写入的Authentication Key。其他读写时，填充MAC值。
2.1.4 MAC计算
MAC通过HMCA-SHA-256计算出，使用的key即为Authentication Key，参与计算的数据区为2.1.3章节RPMB数据结构的Byte[283:0]区域，即Data、Nonce、Write Counter、Address、Block Count、Result、Res/Resp组成的区域。
MAC计算和校验过程如下方示意图：
-
- 当eMMC响应需要MAC值时，eMMC会使用Authentication Key作为密钥，基于HMAC-SHA256算法，以RPMB Data Frame的Byte[283:0]所在区域的数据为输入（RPMB操作数据结构见2.1.3章节介绍），计算出MAC值
-
- 将计算出的MAC值附加在Byte[315:284]区域。随后将RPMB操作数据结构响应给Host/工具库
-
- 当Host/工具库接收到RPMB Data Frame时，Host/工具库遵循步骤1相同计算MAC的方法，计算出1个MAC值，并对比是否和接收到的RPMB Data Frame中Byte[315:284]是否相等。若相等，则MAC校验通过，数据可信。若不相等，则MAC校验不通过，数据不可信。
- 4.若Host/工具库需计算MAC时，方法和以上步骤一致。仅接收方和发送方互换。
2.2 RPMB操作
eMMC提供4种方式操作PRMB，通过如下4种方式即可实现对RPMB的所有操作
-
- 写入Authentication Key
-
- 读取Write Counter值
-
- 向RPMB写入数据
-
- 从RPMB读取数据
在进行RPMB操作前，必须通过CMD6设置EXT_CSD寄存器的PARTION_ACCESS标志。如此设置后，方可通过CMD18/CMD23/CMD25操作RPMB区域。当不需要操作RPMB区域时，应清楚PARTION_ACCESS标记。
2.2.1 写入Authentication Key
写入密钥总体流程如上图：
-
- Host端应用程序（例如linux进程）调用工具库（例如mmc-utils等）进行Authentication Key写入，此时需传递入参：待写入的Authentication Key、rpmb设备标识
-
- 当工具库接收到写入请求后，会遵循eMMC规范J6M，首先使用CMD23，设置block count为1，bit[31]为1。若不进行如此设置，后续CMD25将返回通用失败0x01/0x81
-
- 使用CMD25，发送如下图的RPMB Data Frame，其中bit[315:284]的Key/MAC处填充需要写入的Authentication Key，Req/Resp值为0x0001，表明是RPMB Authentication Key写入请求
- 使用CMD25，发送如下图的RPMB Data Frame，其中bit[315:284]的Key/MAC处填充需要写入的Authentication Key，Req/Resp值为0x0001，表明是RPMB Authentication Key写入请求
-
- 使用CMD23设置block count为1。若不进行如此设置，后续CMD25将返回通用失败0x01/0x81
-
- 使用CMD25，发送如下图的RPMB Data Frame，其中Req/Resp值为0x0005表明为请求结果
- 使用CMD25，发送如下图的RPMB Data Frame，其中Req/Resp值为0x0005表明为请求结果
-
- 使用CMD23设置block count为1。若不进行如此设置，后续CMD18将返回通用失败0x01/0x81
-
- 使用CMD18，读取结果
-
- eMMC将返回如下图所示的RPMB Data Frame，其中Result值即为Authentication Key写入结果，结果标识符含义见2.1.3章节。
- eMMC将返回如下图所示的RPMB Data Frame，其中Result值即为Authentication Key写入结果，结果标识符含义见2.1.3章节。
2.2.2 读取Write Counter值
读取WriteCounter总体流程如上图：
-
- Host端应用程序（例如linux进程）调用工具库（例如mmc-utils等）进行WriteCounter读取，
-
- 使用CMD23设置block count为1。若不进行如此设置，后续CMD25将返回通用失败0x01/0x81
-
- 使用CMD25，发送如下图的RPMB Data Frame，其中Req/Resp值为0x0002，表明为请求读取WriteCounter值。Nonce为16字节的随机数，此随机数可以由工具库生成，也可以由Host应用生成并传递到工具库，具体策略由工具库决定。
- 使用CMD25，发送如下图的RPMB Data Frame，其中Req/Resp值为0x0002，表明为请求读取WriteCounter值。Nonce为16字节的随机数，此随机数可以由工具库生成，也可以由Host应用生成并传递到工具库，具体策略由工具库决定。
-
- 使用CMD23设置block count为1。若不进行如此设置，后续CMD18将返回通用失败0x01/0x81
-
- 使用CMD18，读取结果，将返回如下图所示的RPMB Data Frame，其中Result值即为读取WriteCounter的状态，结果标识符含义见2.1.3章节。WriteCounter区域为读取到的WriteCounter值。Nonce为第3步中发送的Nonce。Key/(MAC)为eMMC计算出的MAC值。该MAC值计算使用的Key为Authentication Key，数据区为Byte[283:0]。Host应用或工具库应校验Nonce是否为第3步发送的值，以及MAC值是否正确。均校验通过后，方可认为WriteCounter有效，MAC校验过程参考2.1.4步骤。
- 使用CMD18，读取结果，将返回如下图所示的RPMB Data Frame，其中Result值即为读取WriteCounter的状态，结果标识符含义见2.1.3章节。WriteCounter区域为读取到的WriteCounter值。Nonce为第3步中发送的Nonce。Key/(MAC)为eMMC计算出的MAC值。该MAC值计算使用的Key为Authentication Key，数据区为Byte[283:0]。Host应用或工具库应校验Nonce是否为第3步发送的值，以及MAC值是否正确。均校验通过后，方可认为WriteCounter有效，MAC校验过程参考2.1.4步骤。
简化后的关键流程：
-
- 客户端发送到eMMC的读取Write Counter的请求，需具有16字节的Nonce值（随机数）
-
- eMMC接受到读取请求后，读取当前的Write Counter，并将请求中的Nonce值复制到响应中，同时使用Authentication Key计算出有效的MAC值填充到响应中。最后将响应返回客户端
-
- 客户端接受到响应后，应校验
a. Nonce值是否和发送请求中的Nonce值一致
b.使用客户端存储的Authentication Key计算出MAC，并和响应中的MAC值对比，确认是否一致
c.以上均一致，即可认为数据有效
- 客户端接受到响应后，应校验
2.2.3 向RPMB写入数据
向RPMB写入数据的总体流程如上图：
-
- 首先是使用第2.2.2章节流程，读取到当前的Write Counter
-
- Host端发送向RPMB写入数据请求，此时需注意：待写入的地址和block信息、 待写入的数据、步骤1获取的Write Counter、MAC值。实际代码过程中，部分信息可能由工具库自动完成，需结合实际场景具体配置。
-
- 使用CMD23，设置block count为1，bit[31]为1。若不进行如此设置，后续CMD25将返回通用失败0x01/0x81
-
- 使用CMD25，发送如下图的RPMB Data Frame。其中Req/Resp值为0x0003，表明是请求向RPMB写入数据。Write Counter为步骤1中读取到的Write Counter。Data为需要写入的数据。Key/(MAC)为客户端计算出的MAC值，计算MAC细节参考第2.1.4章节。
- 使用CMD25，发送如下图的RPMB Data Frame。其中Req/Resp值为0x0003，表明是请求向RPMB写入数据。Write Counter为步骤1中读取到的Write Counter。Data为需要写入的数据。Key/(MAC)为客户端计算出的MAC值，计算MAC细节参考第2.1.4章节。
-
- eMMC接受到请求数据后。需进行如下校验：
a. 校验Write Counter是否有效(官方说法是expired，我理解是Write Counter达到最大值？意味着Write Counter达到最大值后，将再也无法写入数据)，若无效，则返回Result返回0x75
b. 若地址不合法，返回0x04
c. 若MAC不合法，返回0x02
d. 检查WriteCounter是否和当前eMMC中的一致，若不一致，返回0x03
若以上校验均通过，则进行数据写入和Write Counter自增1。若此时数据写入失败，返回0x05。
- eMMC接受到请求数据后。需进行如下校验：
-
- 使用CMD23设置block count为1。若不进行如此设置，后续CMD25将返回通用失败0x01/0x81
-
- 使用CMD25，发送如下图的RPMB Data Frame，其中Req/Resp值为0x0005表明为请求结果
- 使用CMD25，发送如下图的RPMB Data Frame，其中Req/Resp值为0x0005表明为请求结果
-
- 使用CMD23设置block count为1。若不进行如此设置，后续CMD18将返回通用失败0x01/0x81
-
- 使用CMD18，读取结果
-
- eMMC返回如下图所示的RPMB Data Frame，其中Result值即为数据写入结果。若存在异常，参考步骤5中的返回值信息。WriteCounter为自增1后的值，MAC为eMMC针对此Data Frame计算出的MAC值，详细计算过程参考第2.1.4章节。
- eMMC返回如下图所示的RPMB Data Frame，其中Result值即为数据写入结果。若存在异常，参考步骤5中的返回值信息。WriteCounter为自增1后的值，MAC为eMMC针对此Data Frame计算出的MAC值，详细计算过程参考第2.1.4章节。
简化后的关键流程：
-
- 步骤1/2/3/4主要为读取Write Counter值，详见第2.2.2章节
-
- 步骤5，Host向eMMC请求写入数据，请求中需包含如下信息：上一步获取的Write Counter、需写入的数据以及地址、MAC值
-
- eMMC接受请求数据后，校验Write Counter、地址、MAC等信息，若合法后，执行数据写入。写入成功后，Write Counter自增1.
-
- eMMC响应写入结果。响应中包含：自增后的Write Counter、写入的地址、MAC值、状态码等
-
- Host接收响应后，需校验状态码、MAC值合法性。最终明确写入数据是否成功
2.2.4 从RPMB读取数据
从RPMB读取数据总体总体流程如上图：
-
- Host端应用程序发送读取数据请求，
-
- 使用CMD23设置block count为1。若不进行如此设置，后续CMD25将返回通用失败0x01/0x81
-
- 使用CMD25，发送如下图的RPMB Data Frame，其中Req/Resp值为0x0004，表明为请求读取数据。Nonce为16字节的随机数，此随机数可以由工具库生成，也可以由Host应用生成并传递到工具库，具体策略由工具库决定。address为待读取的数据地址。Nonce为生成的随机数。
- 使用CMD25，发送如下图的RPMB Data Frame，其中Req/Resp值为0x0004，表明为请求读取数据。Nonce为16字节的随机数，此随机数可以由工具库生成，也可以由Host应用生成并传递到工具库，具体策略由工具库决定。address为待读取的数据地址。Nonce为生成的随机数。
-
- 使用CMD23设置block count为1。若不进行如此设置，后续CMD18将返回通用失败0x01/0x81
-
- 使用CMD18，读取结果
-
- eMMC返回如下图所示的RPMB Data Frame，其中Result值即为数据写入结果。address和block count为读取的数据地址信息，Nonce为步骤3中请求时携带的Nonce，Data为读取出的数据内容，Key/(MAC)为eMMC侧计算出的MAC值（详细计算过程参考第2.1.4章节）
- eMMC返回如下图所示的RPMB Data Frame，其中Result值即为数据写入结果。address和block count为读取的数据地址信息，Nonce为步骤3中请求时携带的Nonce，Data为读取出的数据内容，Key/(MAC)为eMMC侧计算出的MAC值（详细计算过程参考第2.1.4章节）
-
- 当Host或工具库接收到响应数据后，应校验MAC和Nonce是否合法。
简化后的关键流程：
-
- Host端发送读取数据请求。请求中包含：待读取数据的地址信息、一个随机数Nonce
-
- eMMC接收读取请求后，检查待读取数据的地址，若有效，则读取出数据。并将请求中的Nonce复制到响应中，随后计算出有效的MAC值也附加在响应中
-
- eMMC返回响应信息，包含：读取的数据内容、Nonce值、MAC值
-
- Host端检查Nonce值是否和请求中发送的一直（步骤1）、MAC值是否合法。若都验证通过，则数据可信，可使用读取的数据。
四、RPMB安全机制思考
4.1 认证和防重放实现
前文说到RPMB可以提供认证（Authentication）和防重放机制。因为RPMB共有4中场景结合场景简单分析下。当然首先有个前提：攻击者无法获取到Authentication Key。若攻击者已知晓Authentication Key，那所有防护机制将无效。
4.1.1 写入Authentication Key
此场景没有任何防护机制。通常此动作是在可信环境（例如己方工厂生产阶段等），而且Authentication Key仅写入一次，后续不会再写入，即便发起写入Authentication Key，也会写入失败。因此不做防护机制也可以理解。
4.1.2 读取Write Counter值
此时Host是请求方，因此安全重点是确认eMMC返回的数据是真实eMMC响应的，而不是中间人重放或非法方伪造的，确保读取到的Write Counter是可信的。Write Counter没有机密性的需求。再看数据交互：Host请求读取Write Counter时，请求数据中会带一个随机数Nonce，当eMMC响应的时候，会将请求的Nonce回传并且带有MAC值，HOST接受到数据后校验Nonce和MAC。结合攻击场景：
-
- 若攻击者截获请求中的Nonce值，然后伪造响应。因攻击者不知道Authentication Key，就无法伪造出有效的MAC值。Host接收到响应，使用自己持有的有效Authentication Key计算出一个MAC值，必然和响应中的MAC值不一致，因此Host就知道响应不是合法eMMC发送的。
-
- 若攻击者截获上一次读取Write Counter时，eMMC真实的响应数据。随后再Host再次请求读取Write Counter时，直接将此数据返回给Host。此时Host校验MAC是可以通过的，因为此响应的确是eMMC返回的，只不过是上次返回的。但Host会校验Nonce是否和本次请求的Nonce一致，因此也可以检测出响应数据不是本次eMMC发出的。
- 3.如果攻击者直接请求读取WriteCounter，是可以读取有效值的（此时攻击者不校验MAC即可，但不校验MAC，攻击者也无法确认读取的Write Counter是否一定是eMMC发出去的）。但Write Counter其实无机密性要求，理论上任何终端都可以读取，eMMC没有区分终端是否合法的需求。即便攻击者读出Write Counter也无法进行写操作（4.2.3章节）
4.1.3 向RPMB写入数据
写入数据前，需先进行Write Counter读取，WriteCounter分析和4.1.2章节一致。依据攻击场景分析：
-
- 假设攻击者通过发送读取Write Counter读取出1个Write Counter值（攻击者因为不校验MAC，实际是不能确认当前读取的Write Counter是否一定是有效的，此处假定Write Counter有效）。随后攻击者需要构造写入数据的指令，此时因攻击者无有效的Authencation Key，因此无法算出有效的MAC值，eMMC接收到写数据请求时，MAC必定校验不过，因此eMMC拒绝写入。
-
- 假设攻击者截获了之前有效Host(具有有效Authencation Key的终端)发送的请求写入数据（称为DataA）。并且攻击者作为Host再次发送之前截获的有效数据DataA，此时eMMC接收到请求数据DataA后，当校验Write Counter时，必定校验不过。因为之前DataA上次成功写入后，eMMC已经对Write Counter自增1了，此时eMMC会发现Write Counter不匹配，因此依然拒绝写入（但当Write Counter达到最大值，不在自增时，此时RPMB已经处于只读状态，合法写入请求也无法写入，参考2.2.3章节的步骤5）。同样如果攻击者这个时候读取1个正确的Write Counter，然后去修改DataA里的Write Counter为正确值，因为修改了DataA的Write Counter，也会导致DataA中的MAC和当前数据不匹配，攻击者将修改后的DataA发送给eMMC，eMMC可以通过校验MAC失败出数据不合法。
-
- 假设攻击者篡改步骤7，伪造虚假的写入状态（例如实际写入成功，告诉host写入失败，实际写入失败，告诉Host写入成功）。因返回值中具有MAC，因此Host也可有效失败写入结果是否合法。
4.1.4 从RPMB读取数据
读数据其实和读取Write Counter的逻辑是一致的，可参考4.1.2章节。但此时会有个问题，在4.1.2的场景3中，攻击者可以成功读取WriteCounter（不校验MAC，只是不能确保读到的数据一定是合法的，也可能是其他攻击者伪造的）。同样的逻辑，攻击者也可以读取到RPMB的数据（假设此时无其他攻击者），这会导致RPMB数据的机密性丧失。
4.2 RPMB使用
通过第4.1章节的分析，当从信息安全角度考虑，使用RPMB时，需关注2个核心点：1. Host端的Authencation Key防止泄露。2.从RPMB读取出的数据没有机密性保护。
4.2.1 Host端Authentication Key保护
当使用RPMB读写数据时，都涉及到Host使用Authentication Key来校验MAC，若Authentication Key卸载代码中或简单存储在文件系统中，攻击者是比较容易能找到Authentication Key。因此Authentication Key必须进行安全存储，否则Authentication Key一旦泄露，RPMB安全存储机制基本就失去价值。
-
- 首先我们需要向eMMC写入Authentication Key。通常这个写入环境处于自有工厂，相对安全性较高。因此写入Authentication Key过程可以不保护，也可以进行保护。
- 2.读写RPMB数据时，需要使用Authentication Key进行MAC校验，此过程必须进行保护，确保Authentication Key不外泄。如下图，可以使用HSM/TEE来实现保护。Authentication Key存储在efuse中，计算CMAC过程在HSM内部进行，这样可以保证Authentication Key不会流出到HSM外。对eMMC响应数据的处理也在TEE中进行，确保处理响应数据流程不会被篡改。实际可结合具体场景做一定变化，例如Authentication Key是通过efuse中的Key派生等
4.2.2 RPMB读取数据的机密性保护
核心是看RPMB的数据是否有机密性的需求。如果无此需求，则不用关注。如果有这个需求，那就需要在RPMB机制外，对读写数据进行加解密操作，例如AES-128-CBC。如果对数据进行加解密操作，进一步涉及到加解密密钥的保护，加解密密钥保护可参考4.2.1对Authentication Key保护。
五、总结
RPMB是eMMC规范中定义的一个标准流程，主要提供认证机制和防重放机制。当嵌入式环境中使用eMMC场景，同时有安全存储需求时（尤其是认证和防重放），即可考虑使用RPMB机制。但在使用RPMB机制时，因Host端Authentication Key保护和数据机密性不在规范定义范围，因此需要集合实际场景，考虑Host端Authentication Key保护方案以及数据机密性保护方案，这样实施下来的安全存储安全性才更高。