假设我的数据不是特别机密，但是根据这个问题，只要实际上没有很大的设计成本，我可能就需要考虑对其进行加密。
为简单起见，假设我使用的是nRF51822 SoC，该SoC还支持BLE堆栈和更简单的2.4 GHz协议。
因为我考虑的是商用产品应用，而不是一个在安装后，加密需要大量的计算才能破解（例如，2016年云计算至少需要500美元），而不是简单的混淆。即使访问设备固件也可以保持安全。
#1 楼
您的大部分精力可能会花费在RF传输上，而不是花费在加密例程中的CPU周期。传输的每增加一位将比您提议的加密花费更多的功率。这意味着如果您采取幼稚的方法（例如在CBC模式下使用AES），则可能会增加消息大小，以在每个块中携带额外的位。如果您确定自己的业务需要对数据进行加密， ，请考虑在CTR模式下使用AES生成流密码位。计数器模式适用于处理接收不可靠且数据包可能丢失的情况。您必须保持计数器同步，因此请注意，定期发送计数器的值会增加开销。而且，您必须保留一些状态字节来保存计数器，因为重复使用加密的位流可以直接导致数据恢复。
评论
听起来很有说服力，并且对这个问题有不同的看法，我这次对此并没有考虑太多。
– Sean Houlihane
17年1月20日在21:32
请注意，CTR不提供数据真实性。除非您了解为什么应用程序中不考虑真实性，否则应使用经过身份验证的加密模式。
–吉尔斯'所以-不再是邪恶的'
17年1月20日在22:34
#2 楼
您可以使用多种加密方法来保护流量，每种加密方法的电源使用情况都略有不同，因此，我将选择几种流行的选择。我用来评估每种方法的方法应该适用于您发现并希望进行比较的任何其他密码。AES
AES是最流行的对称密钥加密之一。算法（这意味着您使用相同的密钥进行加密和解密）。就安全性而言，AES是一个安全的选择：
最佳公共密码分析
虽然已经发布了比完全暴力攻击在计算上更快的攻击，但是截至2013年，没有一个在计算上可行。
-Wikipedia
完整AES的Biclique密码分析描述了AES-128需要2126.1操作，AES-192需要2189.7个操作，而AES-256需要2254.4个操作才能中断。在2.9 GHz处理器上，假设每个“操作”为1个CPU周期（可能不正确），则破坏AES-128将花费很长时间。如果其中有10000个运行，它将仍然需要几乎永远的时间。因此，在这里安全性不是问题。让我们考虑一下功率方面。
本文显示（第15页），使用351 pJ的AES加密块。在讨论其他一些常见算法之后，我将对此进行比较。
SIMON
我之前问过一个关于SIMON和SPECK的问题，值得一读。 SIMON擅长的地方是需要经常加密一点数据的情况。我之前链接的论文指出，SIMON 64/96对于64位使用213 pJ，当您只需要发送32位有效负载时，这非常实用。
SIMON 64/96比破解容易得多AES虽然;我链接的论文建议进行263.9次运算，因此我们的1万个CPU设置仅用几年即可破解加密，而不是数百万年的历史。
真的重要吗？
按照您打算传输的速度，答案几乎肯定是“否”。加密的能耗将完全可以忽略。对于AES，您每天将使用50544 pJ，因此，便宜的，能量为2340 J的碳锌AA电池的使用寿命将远远超出设备的使用寿命。如果您使用SIMON重新评估计算结果，您会发现它的使用寿命也很长。
总之，除非您非常频繁地发送信号，否则无线电对功率的影响更大。 Wikipedia引用的功耗在0.01到0.5 W之间。如果以0.01 W传输1秒钟，则整天使用的功率已经超过AES。
对于BLE，您只需要依靠默认的安全性就可以了； BLE默认情况下使用AES-CCM来实现链路层安全性：低功耗蓝牙中的加密使用AES-CCM加密。像BR / EDR一样，LE控制器将
执行加密功能。此功能使用FIPS-1971中定义的AES-128位块密码从128位密钥和128位明文数据生成128位cryptodData。
令人担忧的是，BLE的链路层安全性实现存在安全性缺陷。这不是AES的缺陷；蓝牙SIG决定在4.0和4.1中推出自己的密钥交换机制。由于现在支持椭圆曲线Hellman-Diffie，因此在4.2中已解决了该问题。
评论
“在2.9 GHz处理器上，假设每个'操作'是1个CPU周期（可能不正确）”-可能由运行速度较低但每个周期产生多个结果的并行处理器（例如GPU）进行了补偿（甚至在CPU IIRC上，在单核上实现接近1个操作/时钟的性能]。它不会太大地改变数量级。
– Maciej Piechotka
17年1月21日在3:46
@MaciejPiechotka很好。正如您所建议的那样，数量级不应受到太大影响，在我们正在研究的规模上，因子10仍然是微不足道的（10 ^ 33天与10 ^ 32天无关紧要很多！）。
–Aurora0001♦
17年1月21日在10:43
除非每个设备都具有唯一的密钥，否则像AES这样的对称系统会出现问题-否则，从一个单独的样本中获取密钥就会破坏整个系统。
–克里斯·斯特拉顿（Chris Stratton）
17年1月21日在19:52
#3 楼
除非您使用硬件加速加密，否则当您拥有一个本质上要满足基本（而非加密）需求的处理器时，功耗可能会很高。但是，在大多数情况下，无论如何，还是使用无线电消耗最多的功率。由于您正在专门研究蓝牙SOC，因此请考虑BGM-111，它具有硬件加速加密功能芯片。我玩过这款芯片，而且看起来不错，尽管我没有专门研究加密功能。
另一种方法，如果您想确保没有人能得到的话，可能是“最佳”方法您的钥匙，即使它们拆卸了设备也是如此。它包含一个TPM芯片，例如OPTIGA TPM，该芯片具有Linux内核支持的I2C和SPI TPM芯片。简而言之，您无需特殊的硬件加密即可烧毁电池。要么使用TPM芯片构建电路板，要么选择已经内置了硬件加密功能的更现代的SoC。
评论
问题是建议使用2.5GHz SoC，并每10分钟发送32位值。加密所需的计算量完全可以忽略不计。诚然，SoC似乎确实无法胜任这项任务。但是对于每10分钟32位的内存，您可以找到的最便宜的基本处理器将绰绰有余。
–吉尔斯'所以-不再是邪恶的'
17年1月20日在22:32
每隔10分钟，加密需要多少时间就无关紧要，只需要多少能量即可。您必须查看诸如寄生负载之类的实现细节，以找出在1毫秒内完成工作的快速芯片或在500毫秒内完成工作的慢速芯片是否会在功耗上获胜，假设这两种芯片在不忙时都有效地进入了睡眠状态。硬件引擎可能比软件更好，但是对于能源效率而言，使引擎更快地完成工作是无关紧要的。
–克里斯·斯特拉顿（Chris Stratton）
17年1月21日，19：56
评论
“即使访问设备固件也可以保持安全。”意味着您要么需要使用非对称密码来进行反向计算就很昂贵，要么需要在无法检索或无法对其进行恢复（已知的明文攻击等）的地方存储对称密钥。通常，在后一种情况下，产品的每个副本都具有唯一的密钥，因此从一个样本中进行恢复不会破坏整个系统。但这意味着您的接收器需要存储所有这些密钥。