STM32**有多难？

只看该作者 · 2014-6-13 14:31

今天回顾此贴，当时的元老现在估计更有发言权，总结下更好！

只看该作者 · 2014-6-13 18:29

以CPU的ID号为密钥，配合一定的算法进行计算得到结果，然后将结果写入到程序的末尾，在程序启动运行时再以CPU的ID计算密钥，和程序结尾处的结果核对，如果相符，则运行程序，否则则不运行

只看该作者 · 2014-6-14 12:34

**STM32是肯定的，并且不花多少钱，还很快……硬件加密基本可以无视，只是增加点**的入门成本，免得谁都可以拿个调试器debug一下。
软件加密最好是加密关键数据，运行时解出来用。这样更换芯片后，解出来的关键数据是错误的（不要管），但是程序出现异常的地方却是随机的，不会在解密的地方出问题，汇编级别很难跟踪。而如果是判断方式的话，只需要把判断的语句换成NOP或者JMP就完蛋了（前提是找到判断的地方，这个还是不难的）。

只看该作者 · 2014-6-14 19:51

菜鸟说一句：目前有个非对称rsa加密方式，要想运行此软件必须先输入密文，采用cpu id作为要加密的字符串，运行程序必须用户输入密文，而代码中我们是采用明文解密的，根据rsa原理，那是非常耗时才能**的，即使你在一个ic上**了，换一个ic就不行了。

只看该作者 · 2014-6-14 23:59

adwei 发表于 2014-6-14 12:34
**STM32是肯定的，并且不花多少钱，还很快……硬件加密基本可以无视，只是增加点**的入门成本，免得谁 ...

一般来说会用加密的程序员都不会让程序出现明显的异常，常用的方法一般都是关键地方进行校验，而且校验的地方肯定不会只是一次，或者通过使用从操作系统，在校验密钥通不过的时候不启动某些关键任务，这种方法可以让**的人花费巨大才能得到代码，而且得到的代码永远都不知道什么时候会出错。MD5、DES、AES，甚至简单的base64加密的算法，在用96为CPU的ID作为密钥的情况下进行解密，就目前这计算机的计算成本，我估计不会比自行开发需要的成本低
PS：目前很多程序都有自动损毁功能，在多次尝试密钥失败的情况下，可以通过IAP技术擦除掉程序中的一些内容，比如第XX个扇区的内容，从而让程序出现出现很多莫名其妙的错误。这种技术目前已经在多个项目中使用了

只看该作者 · 2014-6-15 19:43

本帖最后由 huzi2099 于 2014-6-15 19:52 编辑

估计6W是找人代工的价格,山外有山啊.
楼上的不要谈软加密种种,不现实.一旦代码从flash里弄出来被安装到模拟器上,软加密都会显得苍白无力.
硬加密是简单易行的方法,只能寄希望于st了.

只看该作者 · 2014-6-15 20:01

jar1866 发表于 2014-6-14 19:51
菜鸟说一句：目前有个非对称rsa加密方式，要想运行此软件必须先输入密文，采用cpu id作为要加密的字符串， ...

绕过就是了,谁那么傻?

只看该作者 · 2014-6-15 20:07

我在网上找到一个**AVR的。先把封装腐蚀掉，然后用探针，照射等方式吧加密的的部分修复或者读出。还留下了联系方式。。。。哦。。。。。
谁要想**AVR的。就去找他吧。

只看该作者 · 2014-6-15 21:28

jar1866 发表于 2014-6-14 19:51
菜鸟说一句：目前有个非对称rsa加密方式，要想运行此软件必须先输入密文，采用cpu id作为要加密的字符串， ...

你能想象单片机的系统还要向用户索要密码的情形吗?

只看该作者 · 2014-6-16 08:40

huzi2099 发表于 2014-6-15 19:43
估计6W是找人代工的价格,山外有山啊.
楼上的不要谈软加密种种,不现实.一旦代码从flash里弄出来被安装到模拟 ...

按照您的观点，只要上模拟器，神马银**、羊城通的目前我们所有的加密都可以失效了。不要低估了DES、AES、MD5解密的难度

只看该作者 · 2014-6-16 08:52

huzi2099 发表于 2014-6-15 21:28
你能想象单片机的系统还要向用户索要密码的情形吗?

这不用去想象，这早就是现实了，我们目前项目已经正在使用这个方法：
在应用程序中预留通信接口和命令，首先把应用程序写进去，应用程序会使用CPU 的ID号和加密算法进行计算密钥：
1、如果此时单片机密钥区里面的128位密钥全部1，则不启动应用程序，只是启动通信和UI，这个时候生产软件通过通信接口发送读取CPU的ID号的命令，CPU返回自己的ID号和软件版本，生产软件通过这两个信息计算出密钥，然后再使用通信接口把这个生成的密钥发回给下位机，下位机把这个密钥写入到CPU内部Flash的某些位置，同时CPU重启；
2、如果单片机发现密钥区里面的128位密钥不全部为1，则意味这密钥已经被写入，则使用CPU的ID和软件版本号计算密钥，如果密钥不对，则意味着正在被人**，此时通过IAP的方法将程序的后一半和密钥区域擦除，CPU重启；
3、如果密钥校验通过，则正常启动其他业务任务

注意：密钥的写入在公司生产的时候通过生产工具逐台写入的，也就是说，正常客户拿到的产品的密钥肯定是对的，所以正常客户根本感觉不到密钥这东西的存在，但是一旦进行解密或者尝试修改密钥，则会导致内部程序损毁。
顺带告诉大家：实际上CPU 的ID就是私钥，而软件版本的作用就是选择加密算法和公钥。也许有人会认为这种加密方法很复杂，但是实际上很简单，我们在ST的全系列CPU上已经实现了。而且有一个非常实用的方法，使用base64，不同的软件版本对应不同的编码区域，这样会让**你产品的人付出更大的代价。

只看该作者 · 2014-6-16 10:23

runningwzf 发表于 2014-6-16 08:52
这不用去想象，这早就是现实了，我们目前项目已经正在使用这个方法：
在应用程序中预留通信接口和命令， ...

如果代码被反汇编结构实际就已经被一览无余了,软加密的命门在如何防止程序绕开校验,这需要在运行中随机的产生校验,一旦出错就崩溃了.
然后开销也是个问题,这个是在单片机系统里是主要的矛盾.

只看该作者 · 2014-6-16 10:38

runningwzf 发表于 2014-6-16 08:40
按照您的观点，只要上模拟器，神马银**、羊城通的目前我们所有的加密都可以失效了。不要低估了DES、AES ...

这个东西和系统不同,操作和代码是看不到的,那剩下的就是蒙数据了所以难.

只看该作者 · 2014-6-16 15:46

没有**不了的软件，只是增加**难度。
使用CPI ID加密的最大破绽是无法隐藏对CPU ID的访问，不管如何变换花样，使用数据断点都很容易跟踪到；
内联方式的多处校验，包括对程序自身的校验，也无法避免代码雷同的问题；

产品依赖在线服务是目前比较理想的方法，设备根本都不用加密；并且卖设备或许都不挣钱，卖的是服务。

只看该作者 · 2014-6-19 12:38

huzi2099 发表于 2014-6-16 10:23
如果代码被反汇编结构实际就已经被一览无余了,软加密的命门在如何防止程序绕开校验,这需要在运行中随机的 ...

1、反汇编的代价是不小的，就一般的单片机项目而言，其时间成本和经济成本不会比自行开发低
2、现在单片机，当然我指的是cortex这一类，就本人的实际项目应用而言，常用的加密算法需要的资源是绰绰有余的

只看该作者 · 2014-6-19 21:09

adwei 发表于 2014-6-16 15:46
没有**不了的软件，只是增加**难度。
使用CPI ID加密的最大破绽是无法隐藏对CPU ID的访问，不管如何变 ...

我赞同，只要能接触到实物的产品应该都可以被**，只是时间问题而已，我们能做的只是增加他**的复杂度，提高他**需要付出的成本，从而使其放弃**
由硬件向在线服务是一个不错的想法，就像乐视一样，但是说实话，有几个单片机能上网的？就算能上网，安全怎么保障？

只看该作者 · 2014-6-20 00:31

zheng79 发表于 2009-12-14 17:46
刚才理解错了,
读保护后,前3页是不能改的,
不过根据那编**所说的,除了前3页之外都是能改的.

试验过，一旦打开读保护功能，flash的用户区最开始那一片不能改，后面的可以改，相关手册上写的很清楚。

只看该作者 · 2014-6-20 00:35

香水城发表于 2009-12-14 17:31
3楼提到的这篇**首先用一个例子说明了不好的Bootloader所存在的巨大风险，然后提醒大家在自己编写IAP Boo ...

香主，请问你说的**在哪里？我之前设计bootloader时压根就没注意进行更复杂的加密或者更复杂的运行机制，只是简单的打开读保护而已。

另外，对于F4系列的片子，官方说内部带有熔断功能，直接把jtag以及SWD口锁死了，这种方式不会影响内部的IAP吧？

1万 · 2014-6-20 13:08

**我已经不记得了。。。

既然是引用3楼的话，那去问问3楼的ID吧。

至于你说的当JTAG fuse的时候，就是把读保护设置成级别2时，IAP仍然继续正常工作，就是说从片上flash运行的代码仍然能够对flash的其他page进行擦除和编程。

STM32**有多难？

荣誉元老奖章

坚毅之洋流

十世金身

技术领袖奖章

技术高手奖章

以坛为家

涓涓之细流

技术新星奖章

希望之星奖章

七世轮回

欢快之小溪

社区建设奖章

经常做客

技术奇才奖章

缘定三生

甘甜之泉水