简单说一下背景,目前计划在CH558上实现一个bootloader,并且计划加上固件加密功能。
初步想法是实现一个简单的对称加密算法,密钥存储在单片机上,bootloader从USB接收加密后的程序,并在本地解密之后写入到Flash中(这一步可以添加校验以确保固件来源可靠)。只要在bootloader部分不提供密钥区的访问,这样应该是安全的。
那么问题来了,现在需要在单片机上实现一个简单的加密算法(准确说只包括解密部分),我的要求如下:
最重要的是空间限制,由于bootloader区域只有2 KB,因此涉及到挂表的算法基本上不是很现实,但多轮加密只要不大复杂应该可行。空间复杂度不要超过O(n)的级别。
时间方面比较宽松,只要不是很慢就可以了(非对称算法似乎不可行?),毕竟Flash的擦除和写入本身也不是很快。
支持细粒度的加密,目测加密块大小在8到1024 Bytes之间,再大就会分成多个block分开加密了。
安全性要足够(暂时不考虑侧信道攻击之类的话题),对密钥格式之类的没有多大要求,只要可以存在单片机上即可。对于bootloader应用,似乎对称加密就可以接受,不需要考虑网络传输的问题。
对于上述要求,我看了一下已有的算法,感觉TEA(以及变种XXTEA)似乎是个可行的选择,不过也有对特定条件下加密强度的担忧(见cryptanalysis - Is TEA considered secure? - Cryptography Stack Exchange)。
大家对这方面有没有什么想法?欢迎交流。
离线
我做蓝牙这块的,目前基本都是aes--但是这个是基于蓝牙芯片的硬件aes,所以占用资源其实很小,这一块是用于空中升级检验的
离线
我做蓝牙这块的,目前基本都是aes--但是这个是基于蓝牙芯片的硬件aes,所以占用资源其实很小,这一块是用于空中升级检验的
确实,对称加密用的比较多的还是DES/TDES/AES这些,而且AES的硬件加速效果也还可以。像STM32的一些单片机就可以对AES进行加解密。
不过AES有字节代换,使用时需要挂个表,操作的轮数也比较多,对于硬件资源有限的单片机来说还是太复杂了些。
离线
谷歌的 “chacha20加密算法” 符合你需求。
离线
谷歌的 “chacha20加密算法” 符合你需求。
感谢推荐。简单看了一下,对代码和内存的要求确实都不算大(当然还是要比XXTEA多一些),不过好不好用还是要编码试试看才知道。
贴个标准地址:ChaCha20 and Poly1305 for IETF Protocols
最近编辑记录 metro (2020-03-16 10:51:10)
离线
楼主项目进度怎么样了?我也想学习这方面的知识。
离线
xxtea
tinyaes
就上面两种可行易用,非数学专业的也不会去尝试破这两种加密,防其他程序员足够了。
代码去github上找,前者代码几十行,后者几百行吧。
离线
可是怎么保管好密钥呢?比如用全志A33给单片机升级(兼加密芯片功能),如何保证密钥不泄露呢?因为全志的linux很容易把文件系统都抖出来。
离线
可是怎么保管好密钥呢?比如用全志A33给单片机升级(兼加密芯片功能),如何保证密钥不泄露呢?因为全志的linux很容易把文件系统都抖出来。
那是硬件来负责的。找原厂,搞不定就换硬件呗。
离线
可是怎么保管好密钥呢?比如用全志A33给单片机升级(兼加密芯片功能),如何保证密钥不泄露呢?因为全志的linux很容易把文件系统都抖出来。
BL出厂烧录密钥,然后之后整个生命周期里面再也看不见密钥。固件在原厂用密钥加密,然后全套推送环节都是加密的,直到最后传到BL里面再现场解密。
离线
关注一下。
我现在的做法是做个256字节的乱序换码表,简单粗暴速度快 但是确实可能没密钥方法好
离线
直接循环异或好了,速度快
离线
最近看到 https://hackaday.com/2020/12/11/remoticon-video-breaking-encrypted-firmware-workshop/ 讲了替换密码的破解方式。讲解的挺清楚的。
离线
另外有人提到Speck比xxtea还能更省flash一些。
https://www.amobbs.com/thread-5715264-1-1.html
离线
使用异或可以了。出厂前编好
离线