做嵌入式物联网开发尤其是用LuatOS这套方案的人迟早都会跟RSA打交道。设备接入、固件防篡改、敏感数据上云这些场景背后全是非对称加解密的身影。LuatOS的核心库把RSA封装成了几个非常简洁的API用起来门槛不高但真正落地时密钥格式、填充模式、分段长度这些细节一个没对齐就是各种报错和通信失败。这篇文章就以LuatOS的rsa库为主线把RSA非对称加解密从原理到实操过一遍重点放在嵌入式端真正干活时绕不开的坑和取舍上。适合已经跑通LuatOS基础工程、想把设备端安全能力做实做稳的开发者参考。1. 整体思路拆解IoT场景下为什么是RSA1.1 非对称加解密到底解决了什么问题在解释LuatOS为什么要把rsa单独做成一个核心库之前得先想明白一件事设备端做通信加密用AES这类对称加密不就行了AES速度快、开销小、实现简单在嵌入式这种资源受限的环境里确实很有吸引力。但对称加密有一个致命短板加密和解密用同一个密钥。这意味着密钥必须同时存在于设备端和服务端一旦设备被逆向分析、固件被提取密钥就跟着泄露了整个系统的加密防线瞬间失效。RSA这种非对称加解密方案把密钥拆成了一对公钥和私钥。公钥可以随便分发私钥自己藏好。用公钥加密的数据只有对应的私钥能解开反过来用私钥签名的数据大家用公钥就能验证。这个特性让密钥管理的压力一下子小了很多——服务器把自己的公钥发出去设备端用公钥加密数据就算公钥被人截获也无法反向推出私钥更不能解密别人发的内容。在LuatOS的物联网项目里最常见的做法是服务器生成一对RSA密钥公钥烧录在模组固件里私钥留在服务器。设备上报敏感数据时用公钥加密服务器用私钥解密。哪怕某个设备被攻破、固件被完整拖出来攻击者拿到的也只是公钥无论如何也无法解密其他设备的数据更没法冒充服务器下发指令。这就是非对称加密在IoT场景里真正的价值所在。1.2 公私钥与加解密、签名的对应关系很多刚开始接触RSA的朋友容易把加解密和签名验签混在一起。其实这两对操作虽然都是RSA但用途和密钥用法是完全相反的。用锁和钥匙来类比就很好懂公钥加密就好比往一个带锁的箱子里放东西这个锁是公钥谁都能拿来锁上箱子但打开箱子只能用私钥这把唯一的钥匙。所以公钥加密、私钥解密解决的是机密性问题——数据传输途中不怕被人偷看。签名验签则是另一个逻辑。私钥签名就像在文件上盖一枚只有自己才有的印章大家用公钥这个“印泥对照卡”来验证印章是不是真的。所以私钥签名、公钥验签解决的是完整性和身份认证问题——数据是不是被人改过、是不是来自可信的发送方。在LuatOS的rsa库里这两个方向各自都有对应的API。加密解密用rsa.encrypt和rsa.decrypt签名验签用rsa.sign和rsa.verify。动手之前一定要先搞清楚自己的业务需要哪种能力不然经常会出现“我用公钥去解密、用私钥去验签”这种把方向搞反的情况返回结果自然是一堆错误。1.3 LuatOS rsa库API全貌LuatOS的rsa库函数不多核心就四五个但每个函数背后都牵扯着密钥格式、填充方式、哈希算法这些参数。我先给出API的整体视图后面再逐个展开函数作用关键参数rsa.encrypt公钥加密明文、公钥DER数据、填充模式rsa.decrypt私钥解密密文、私钥DER数据、填充模式rsa.sign私钥签名待签数据、私钥DER数据、填充模式、哈希算法rsa.verify公钥验签原数据、签名值、公钥DER数据、填充模式、哈希算法rsa.gen_key生成RSA密钥对位数如1024/2048这里有一个和一般桌面端开发很不一样的地方LuatOS的rsa接口直接吃DER格式的密钥二进制数据而不是PEM格式的文本。常见用OpenSSL生成的密钥默认是PEM里面包了一层base64文本还有-----BEGIN和-----END这样的头尾标记。如果直接把PEM字符串塞给rsa接口大概率会得到密钥解析失败的错误。所以实际开发时要么在PC端先把密钥转成DER再烧录要么在Lua代码里做一次base64解码和格式清理。这个内容我放到下一章详细讲。rsa.gen_key这个函数在运行期生成密钥对说实话在MCU上用得不多。一方面模组CPU算力有限生成2048位密钥可能耗时很长另一方面大多数业务场景是服务器生成密钥对、设备端只内置公钥设备端根本不需要生成密钥。它更适合一些特殊的、必须在设备端独立完成密钥协商的场景。2. 核心细节解析密钥格式与填充模式2.1 密钥格式转换DER和PEM别搞混把密钥格式问题单独拎出来讲是因为我见过太多项目在联调阶段卡死在这一步。OpenSSL是RSA密钥生成和使用最常用的工具默认导出的文件都是PEM格式。PEM本身并不是密钥的二进制本体它是在DER二进制基础上做了一层base64编码再套上可读的头部尾部凑成的文本文件。而LuatOS的rsa接口要的是DER数据。转换路径其实不复杂核心是用OpenSSL把PEM转成DER# 生成2048位私钥 openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private.pem # 从私钥中导出公钥 openssl pkey -in private.pem -pubout -out public.pem # 将私钥转为DER格式 openssl rsa -in private.pem -outform DER -out private.der # 将公钥转为DER格式 openssl rsa -in private.pem -pubout -outform DER -out public.der转出来的DER文件是二进制没法直接看也没法方便地复制粘贴到Lua源码里。一般的处理办法是再做一次base64得到一串纯文本base64 -w0 private.der base64 -w0 public.der把输出的一长串文本粘到Lua代码里写成类似这样的形式local PUB_DER_B64 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... local PRI_DER_B64 MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSj...使用前在运行时解码一次local pub_der crypto.base64_decode(PUB_DER_B64) local pri_der crypto.base64_decode(PRI_DER_B64)这里有个经验之谈很多人在PC端测试时习惯直接用PEM文件路径OpenSSL函数能自动处理带头部尾部的PEM。到了LuatOS端接口不会帮你做这些兼容你得时刻记得“先解base64、再传DER”。另外要注意private.der和public.der是两个不同的文件千万别在生成公钥时又把私钥的DER导出来。2.2 填充模式选择PKCS1与OAEPRSA加密有个特性同样的明文加上随机填充之后每次加密出来的密文都不同。这个随机性就是填充算法的功劳。填充不仅是加随机数还负责把明文扩展到和密钥等长的块。选择哪种填充模式直接影响安全强度和单次能加密的数据长度。LuatOS里常见的填充模式有两种对应着不同的加密语义。PKCS1填充RSA_PKCS1_PADDING是最广泛兼容的模式OpenSSL默认加密使用的就是它性能和兼容性都比较平衡。OAEP填充RSA_PKCS1_OAEP_PADDING是更安全的选择算法里引入了哈希函数和更复杂的掩码操作抗攻击能力强。但OAEP要求通信双方都必须支持并且单次能容纳的明文长度更短。填充模式2048位密钥单次明文上限安全性兼容性NO_PADDING256字节很低仅特殊场景一般PKCS1_PADDING245字节中等广泛PKCS1_OAEP_PADDING190字节左右高依赖两端支持如果只是在LuatOS设备和自己服务器之间通信我建议直接上OAEP安全性更好。但要注意服务端语言比如Java、Node.js里对应的RSA解密接口也要选用OAEP模式哈希算法保持一致否则会出现能加密但解密不了的现象。签名时常用的是rsa.SIGN_PKCS1_PADDING这种情况下hash算法默认是SHA系列比如rsa.SIGN_TYPE_SHA256或字符串形式的sha256具体常量名要看当前固件版本的库文档。这里补充一个容易踩的坑填充模式的选择必须加密解密两端完全一致。有些同学在设备端用OAEP加密服务端却用默认的PKCS1去解密结果就是服务端报decryption error。排查问题的时候第一件事就要去核对双方的padding参数是不是同一个。2.3 单次加密上限与分段策略RSA的核心限制是单次处理的数据长度不能超过密钥长度减掉填充开销。以2048位密钥为例密钥长度是256字节如果用PKCS1填充能加密的明文上限是245字节如果用OAEP这个上限还要更小。超过这个长度接口会直接返回失败。实际业务中设备上报的JSON报文很容易超过245字节。比如一个包含设备编号、时间戳、传感器数据的JSON随便就几百字节甚至更多。这时候就需要分段加密。分段思路很简单把明文按上限切片每片独立加密再把所有密文按顺序拼接。local function rsa_encrypt_long(data, pub_der, mode) local max_block 245 -- 2048位 PKCS1_PADDING 时 local out {} for i 1, #data, max_block do local part data:sub(i, i max_block - 1) local enc rsa.encrypt(part, pub_der, mode) if not enc then return nil, encrypt failed at offset .. i end table.insert(out, enc) end return table.concat(out) end对应的解密函数按256字节一个块去切local function rsa_decrypt_long(cipher, pri_der, mode) local block 256 -- 2048位密钥密文块长度 local out {} for i 1, #cipher, block do local part cipher:sub(i, i block - 1) local dec rsa.decrypt(part, pri_der, mode) if not dec then return nil, decrypt failed at offset .. i end table.insert(out, dec) end return table.concat(out) end这套分段逻辑在嵌入式端性能上有代价。每段都要走一遍完整的RSA运算2048位密钥在模组上算一次可能需要几百毫秒。分段越多总耗时越长而且整个过程会阻塞当前Lua协程。所以在设计数据报文时我通常建议最小化传输内容把不必要的时间戳、状态字段精简掉能塞进一个块就绝不搞分段。实在塞不进去就要考虑用混合加密方案AES加密正文、RSA保护AES密钥这是后面章节要展开的话题。3. 实操过程与核心环节实现3.1 环境准备先确认固件带rsa库动手写代码之前先确认自己的LuatOS固件里有rsa库。不同模组、不同固件裁剪配置包含的库可能不一样。最简单的确认方式是直接在设备上执行log.info(rsa, rsa and ok or not support)如果没有输出ok说明固件没有包含rsa库需要重新编译固件或者在LuatOS的构建配置里勾选对应组件。另外rsa库依赖底层的加密算法组件这两个组件的版本要匹配最稳妥的办法是使用官方发布的、版本一致的完整固件包。开发阶段我习惯先在模拟器里跑通算法逻辑再烧到真机上。LuatOS支持在PC端运行环境里测试大部分库函数rsa库在模拟器里的行为和真机基本一致只是性能表现不同。模拟器调试最大的优势是日志输出方便报错信息完整比在真机上串口查日志效率高太多。3.2 用OpenSSL生成并导出密钥从零到可用的完整命令为了让大家能直接照着做我把生成密钥到导出的完整过程串起来每一步都说明做了什么、为什么这么做。第一步生成2048位私钥。位数建议用2048虽然比1024慢一些但安全性好很多。现在很多安全标准和云平台已经明确要求RSA密钥不得低于2048位openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private.pem第二步从私钥导出公钥。公钥文件可以安全地分发给设备端openssl pkey -in private.pem -pubout -out public.pem第三步转成DER格式。LuatOS需要的是DER二进制直接使用OpenSSL的格式转换能力openssl rsa -in private.pem -outform DER -out private.der openssl rsa -in private.pem -pubout -outform DER -out public.der第四步base64编码方便嵌入Lua源码base64 -w0 private.der base64 -w0 public.der第五步把得到的base64字符串分别存入两个Lua文件或者写成常量。注意私钥数据绝对不能提交到公开的代码仓库这是最基本的密钥安全意识。我习惯把私钥base64放在一个单独的本地方案配置里公钥base64则可以和代码一起分发。3.3 加密解密代码落地一份可以直接改的Lua模板有了密钥接下来就是把加解密逻辑写扎实。下面的代码是我在项目里常用的一套模板包含公钥加密和私钥解密两个函数以及对应的调用示例。先看加密侧。设备端只持有公钥负责对敏感数据加密local PUB_DER_B64 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... local function get_pub_der() return crypto.base64_decode(PUB_DER_B64) end local plain_text {\dev\:\868830071234567\,\temp\:36.5} local pub_der get_pub_der() local cipher rsa.encrypt(plain_text, pub_der, rsa.PKCS1_PADDING) if cipher then log.info(rsa, encrypt len, #cipher) end解密侧在服务器上完成但如果你有设备端解密的场景比如设备接收服务器用私钥加密的下发指令再解密执行逻辑是对称的local PRI_DER_B64 MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSj... local function get_pri_der() return crypto.base64_decode(PRI_DER_B64) end local plain rsa.decrypt(cipher, get_pri_der(), rsa.PKCS1_PADDING) if plain then log.info(rsa, decrypt result, plain) end有几个关键点要特别注意。第一个是数据类型Lua字符串可以携带任意二进制数据rsa接口的输入输出都是Lua字符串不用担心密文里有特殊字符的问题。第二个是错误处理加密解密失败时接口会返回nil建议在业务代码里把失败分支写清楚而不是默认它一定成功。第三个是内存占用2048位密钥运算会产生较大的临时缓冲区在内存紧张的模组上要注意堆内存余量必要时用rtos.meminfo()提前观察内存状态。3.4 签名验签保护数据完整性的完整示例加解密解决的是“数据不能被别人看懂”但没法防止数据被篡改。恶意的中间人如果拿不到私钥确实解不开密文但他可以把密文截住、替换成一段他自己伪造的数据。接收方如果直接解密拿到的是垃圾数据甚至可能触发业务逻辑错误。这时候就需要签名验签来兜底。签名的完整流程是发送方对原始数据做摘要用私钥对摘要签名然后把“数据 签名值”一起发给接收方。接收方用公钥对签名值做验签同时重新计算数据的摘要两个结果比对完全一致才说明数据没被改过。LuatOS端的签名代码如下local data {\dev\:\868830071234567\,\temp\:36.5} local pri_der get_pri_der() -- 签名内部会对data做哈希后签名哈希算法显式指定 local sig rsa.sign(data, pri_der, rsa.SIGN_PKCS1_PADDING, rsa.SIGN_TYPE_SHA256) if sig then log.info(rsa, sign len, #sig) end验签代码在设备端或服务器端都常见取决于业务方向local pub_der get_pub_der() local verify_ok rsa.verify(data, sig, pub_der, rsa.SIGN_PKCS1_PADDING, rsa.SIGN_TYPE_SHA256) log.info(rsa, verify result, verify_ok)签名验签和加解密有一个容易混淆的点加解密用公钥加密、私钥解密签名验签用私钥签名、公钥验签。如果发现验签一直失败先检查是不是把公钥和私钥的传入顺序搞反了。另外签名的hash算法必须和验证端一致。比如设备端用的是SHA256服务器端验签时也必须指定SHA256否则两边计算出的摘要不同签名自然验证不过。我在实际项目里经常是“先签名再加密”双管齐下。设备端先对业务数据做签名然后把“数据签名”一起用服务器公钥加密后上传。服务器先解密再验签。这样既保证数据在传输过程中不被偷看也保证数据没有被替换或篡改。双重保护的开销确实更大但用来传输设备激活、密钥协商这类关键业务数据这个开销是值得的。3.5 服务端配合时最容易忽略的五个对齐项设备和服务器做RSA联调时很多问题都不是Lua代码写错而是两端参数没对齐。根据我的经验下面五个项目是检查重点第一密钥对是否匹配。服务器和设备的公钥必须来自同一对密钥。我曾经在联调现场发现设备里烧录的公钥和服务器私钥不是一对整整查了一下午最后换回配套的公钥直接就好了。第二填充模式是否一致。设备加密用PKCS1服务端解密也必须用PKCS1设备用OAEP服务端也要用OAEP。两边默认参数不同是跨语言联调最常见的坑。第三哈希算法是否一致。签名验签涉及的hash算法、OAEP内部使用的MGF1哈希都要核对清楚。比如Java的Cipher.getInstance(RSA/ECB/OAEPWithSHA-256AndMGF1Padding)里隐含的参数和LuatOS端如果不匹配一样会失败。第四密文编码方式。RSA加密后是二进制数据很多物联网设备走MQTT或HTTP上传密文时都要先做base64编码转成文本。服务端拿到后要记得先base64解码再执行RSA解密。漏掉这一步服务端看到的是一串乱码解出来的也是乱码。第五数据长度上限。设备端分段加密时要确保服务端也实现了对应的分段解密逻辑或者至少能处理拼接后的完整密文流。尤其要注意分段后密文块的长度等于密钥长度256字节一块不要按明文长度去切。4. 常见问题与排查技巧实录4.1 错误现象速查表先对照这张表再动手查联调阶段收到的报错和异常通常就那么几类。我整理了一张速查表按现象、原因、排查顺序三个维度来写能解决大多数问题。错误现象常见原因排查与解决rsa.encrypt返回nil明文过长、填充模式不支持、公钥格式错误检查明文长度是否超过上限确认填充模式确认传入的是DER而非PEM、是否已base64解码rsa.decrypt返回nil或乱码私钥格式错误、密文被截断、填充模式不匹配核对私钥DER检查密文传输时是否丢失字节确认两端padding一致验签一直失败公钥和私钥不配对、hash算法不一致、验签数据被改动核对密钥对统一hash算法确认验签用的data与签名时完全一致服务端解密报错服务端与设备端密钥格式/参数不一致重点核对DER/PEM、padding、base64解码三步加密后密文长度异常使用了错误的密钥长度或误用了NO_PADDING确认密钥位数NO_PADDING下要自己保证明文长度等于密钥长度设备卡顿严重2048位密钥在低主频模组上计算耗时过长合理设计数据大小以减小分段数优化业务逻辑避免频繁加密这张表之外还有一个经常被忽略的问题数据在传输层经过编码或转义导致变了样。比如用JSON传输时二进制密文直接塞进字符串里遇到不可见字符就可能被破坏。正确做法是先把密文base64放进JSON的字符串字段服务端取出来再解码。4.2 几个典型的踩坑现场第一个坑是“PEM当DER直接用”。这个我前面已经反复强调过。有些同学在PC端写惯了习惯了直接把PEM读进来就能用到了LuatOS端忘了这回事把PEM原封不动传进去结果rsa函数一个nil打回来。解决思路也很简单项目里统一维护一个“密钥转换脚本”一键生成Lua端的base64常量从源头上杜绝格式问题。第二个坑是“中文编码长度没算对”。Lua的字符串长度是按字节算的一个中文字符在UTF-8编码下占3个字节。如果一个JSON里带了中文设备名称计算可加密长度时按字符数去算超过245字节就翻车了。我建议对所有待加密数据统一用#data获取真实字节数不要把字符个数和字节数混为一谈。第三个坑是“低内存模组上加密大数据直接重启”。RSA运算本身需要不小的内存缓冲区加密几十个字节还没啥问题一旦分段加密几百字节的报文临时内存峰值会明显上升。我在Air系列模组上遇到过加密大报文时内存不足导致重启的情况。后来把上报数据压缩精简、减少分段数同时调整了业务频率问题才解决。写代码时可以用rtos.meminfo()提前评估内存余量。第四个坑是“签名数据格式不一致”。签名本质上是对一串字节做摘要。如果设备端签名的data是“abc123”服务端验签时拿到的却是“abc123\n”或者“abc 123”哪怕只差一个空格验签都会失败。保证签名前后数据完全一致的方法是服务端直接把收到的data原样用于验签不要在中间做任何trim、格式化、换行转换。4.3 性能与内存调优的实用建议RSA在嵌入式端最突出的矛盾就是性能和资源占用。2048位密钥的一次私钥运算在中等主频的MCU上耗时可能达到数百毫秒甚至一秒以上。如果你的业务对时延敏感有几个调整思路。第一个思路是选对密钥位数。不是所有场景都需要2048位如果你的设备只用于短时间内的会话密钥交换1024位配合合理的密钥更新策略也能用性能会明显改善。但要注意合规要求很多安全规范强制2048位这个选择不能只看性能。第二个思路是减少调用频率。一次握手协商出AES会话密钥后续业务数据用AES加密这是标准和高效的混合加密方案。RSA只负责最开始的密钥传输环节不让它参与每一条业务数据的加解密。第三个思路是善用异步和超时设计。不要在关键业务路径上同步阻塞太久。LuatOS有协程机制可以把耗时的RSA操作放到独立的任务里执行主任务继续处理其他事情。同时要给加密解密操作设置合理的超时预期避免业务层等待无限期。第四个思路是精简待加密数据。设备上报的内容能精简就精简字段名越短越好单位、时间戳能省则省。一个小技巧是把JSON转成更紧凑的格式比如用数字枚举替代字符串状态字段数据体积能减少30%以上。5. 写在最后的实操体会rsa库在LuatOS里虽然就几个API但它牵扯出来的工程问题从来不少。我个人做了几个IoT项目之后的体会是不要把RSA当成万能加密工具它的定位是“关键数据的保险箱”和“身份的验证器”。日常的海量业务数据该用AES还是用AESRSA只负责保护那些最核心的、量级很小的数据比如AES密钥、设备激活码、固件摘要。另外密钥管理这件事一定要从项目第一天就规范起来。公钥可以大方地放固件里私钥必须锁在服务器端最好是放在硬件密钥管理模块或者至少做权限隔离。开发期生成的测试密钥要和生产密钥分开避免测试密钥流向生产环境。最后给刚上手的人一个建议先在PC端用OpenSSL彻底把流程跑通生成密钥、PEM转DER、base64、加密、解密、签名、验签逐个验证一遍再移植到LuatOS里写代码。RSA的问题十有八九是格式和参数不一致造成的而不是算法本身出了问题。把这套基础打牢项目联调阶段能省下大把时间。
