52 Things: Number 43: Describe some basic (maybe ineffective) defences against side channel attacks proposed in the literature for AES
52 Things: Number 43: Describe some basic (maybe ineffective) defences against side channel attacks proposed in the literature for AES
52 Things: Number 43: Describe some basic (maybe ineffective) defences against side channel attacks proposed in the literature for AES
52件事：第43件：描述AES文献中提出的针对侧信道攻击的一些基本（可能无效）防御措施This is the latest in a series of blog posts to address the list of '52 Things Every PhD Student Should Know To Do Cryptography': a set of questions compiled to give PhD candidates a sense of what they should know by the end of their first year. This week we consider what can be done to mitigate the thread of side-channels against AES implementations...
这是一系列博客文章中的最新一篇，旨在解决“每个博士生在做密码学时应该知道的52件事”：这是一组问题，旨在让博士生在第一年结束时了解他们应该知道什么。本周，我们将考虑可以做些什么来减轻针对AES实现的侧通道线程。。。
Sidechannel defences: Why?
侧通道防御：为什么？
For a modern cryptographic scheme to be taken seriously, we generally require some form of security justification. In the case of AES, we believe it acts like a random permutation if the adversary doesn't know the key. However, if the adversary has side-channel information, it is possible that this is no longer the case. So, what can we do about it? Ideally we would create an implementation that is completely impervious to side-channel attacks. However, this effectively means the implementation must sit in total isolation, with absolutely no output streams - which makes it rather pointless!
为了认真对待现代密码方案，我们通常需要某种形式的安全理由。在AES的情况下，我们认为如果对手不知道密钥，它就像一个随机排列。然而，如果对手拥有侧信道信息，则可能不再是这种情况。那么，我们能做些什么呢？理想情况下，我们将创建一个完全不受侧通道攻击影响的实现。然而，这实际上意味着实现必须完全隔离，绝对没有输出流——这让它变得毫无意义！
Perhaps we can make sure that whatever we do, it doesn't matter if the AES implementation leaks information through side channels? This leads to the field of leakage resilient cryptography, which is a very strong security requirement indeed. As such, schemes secure in these conditions (of which there are very few) tend to be drastically less efficient than those which avoid (/ignore) the problem. Since trade-offs must always be made in design, in practice we tend to use schemes that assume AES doesn't leak any information, and combine them with implementations that contain defences against some of the simpler side-channel attacks. The hope is that this pushes the attack cost beyond the value of the information secured and so (even though they could) no adversary will bother attacking the system because it is no longer viable.
也许我们可以确保，无论我们做什么，AES实现是否通过侧通道泄露信息都无关紧要？这导致了泄漏弹性密码学领域，这确实是一个非常强的安全要求。因此，在这些条件下安全的方案（很少）往往比那些避免（/忽略）问题的方案效率低得多。由于在设计中必须始终进行权衡，因此在实践中，我们倾向于使用假设AES不会泄露任何信息的方案，并将其与包含防御一些更简单的侧信道攻击的实现相结合。希望这能将攻击成本推高到安全信息的价值之外，因此（即使他们可以）没有对手会因为系统不再可行而麻烦攻击系统。
Some Basic Defences 一些基本抗辩
So, with that in mind, let us consider a couple of basic defences against some of the less sophisticated side-channel attacks. As pointed out in the question, these techniques may be easily bypassed, so think of this post as explaining the general concept, rather than providing any sensible suggestions!
因此，考虑到这一点，让我们考虑一些基本的防御措施，以对抗一些不太复杂的侧通道攻击。正如问题中所指出的，这些技术可能很容易被绕过，所以把这篇文章看作是解释一般概念，而不是提供任何明智的建议！
Attack: Timing Attack 攻击：定时攻击
Weakness: Some implementations run in different times depending on their inputs. As such, by observing how long the system takes to respond one learns something about the key/inputs.
弱点：一些实现根据其输入在不同的时间运行。因此，通过观察系统需要多长时间才能做出响应，人们可以了解一些关于按键/输入的信息。
Defence: Constant time implementations. As the title says, the best defence against a timing attack is to make sure the implementation takes constant time, and most implementations will be
防御：持续时间实施。正如标题所说，对定时攻击的最佳防御是确保实现需要持续的时间，而大多数实现都是 constant-time nowadays. This might not be too hard in hardware, but in software it can be very difficult indeed, because the microcode (the internal programming of the processor) is generally a trade secret and open to change.
现在时间不变。这在硬件上可能不太难，但在软件上可能确实非常困难，因为微码（处理器的内部编程）通常是商业秘密，可以更改。
Attack: Power Analysis (DPA,SPA)
攻击：功率分析（DPA，SPA）
Weakness: The power usage of some implementations is correlated with the key material, often due to the hamming distance when storing values. For more information, read the blog from two weeks ago.
弱点：一些实现的功耗与关键材料相关，通常是由于存储值时的汉明距离。欲了解更多信息，请阅读两周前的博客。
Defence (1): Masking Rather than using the AES Sbox directly, one applies a mask to the input value, and looks this up in a masked Sbox (which is effectively the Sbox with its values reordered to accommodate the mask). Then, even though the attacker may be able to detect correlations between certain internal variables, these are all masked, and do not [directly] correspond to the key material as they had previously. More complex masking schemes will be more complex to instantiate, but lead to better resistance to attack.
防御（1）：掩码不是直接使用AES Sbox，而是将掩码应用于输入值，并在掩码Sbox中查找它（实际上是对其值进行重新排序以适应掩码的Sbox）。然后，即使攻击者能够检测到某些内部变量之间的相关性，这些变量都被掩盖了，并且不像以前那样[直接]对应于关键材料。更复杂的掩蔽方案实例化起来会更复杂，但会更好地抵抗攻击。
Defence (2): Shuffling To conduct a power analysis attack, the attacker uses the fact they know the internal structure of the AES scheme. If we shuffle the order of the S-boxes in our implementation (by some secret permutation), the adversary will not know how their readings correspond to the internal key materials. A variation on this is the deliberate use of non-determinism, allowing the processor to reorder certain collections of instructions on it's own.
防御（2）：洗牌为了进行功率分析攻击，攻击者利用他们知道AES方案的内部结构的事实。如果我们在实现中打乱S盒的顺序（通过一些秘密排列），对手将不知道它们的读数如何与内部密钥材料相对应。对此的一个变体是故意使用非确定性，允许处理器自行重新排序某些指令集合。
Attack: Cache-flooding 攻击：缓存泛滥
Weakness: Implementations using lookup-tables (eg for the SBox) will be more or less efficient if the appropriate cells are already in the processors cache. By pushing most of the lookup table out of the cache, an attacker can observe whether the appropriate cells are called, leaking information. Can also be observed as a timing attack or by power analysis if the cost of loading the cache can be observed.
弱点：如果适当的单元已经在处理器缓存中，那么使用查找表（例如SBox）的实现或多或少会有效率。通过将大部分查找表从缓存中推出，攻击者可以观察是否调用了相应的单元格，从而泄露信息。如果可以观察到加载高速缓存的成本，也可以观察到定时攻击或通过功率分析。
Defence: Dont use lookup tables on secret data! The simplest defence in this list - if you don't want to leak information about which lookup entries have been used, don't use lookup tables. In the case of AES this is reasonable, because the AES Sbox can actually be computed as a simple function on the input byte. This would be much less practical with (for example) the DES Sbox, which does not have this structure.
防御：不要在秘密数据上使用查找表！这个列表中最简单的防御措施是——如果你不想泄露关于使用了哪些查找条目的信息，就不要使用查找表。在AES的情况下，这是合理的，因为AES Sbox实际上可以作为输入字节上的简单函数来计算。这对于（例如）没有这种结构的DES Sbox来说将不太实用。
这是一系列博客文章中的最新一篇，旨在解决“每个博士生在做密码学时应该知道的52件事”：这是一组问题，旨在让博士生在第一年结束时了解他们应该知道什么。本周，我们将考虑可以做些什么来减轻针对AES实现的侧通道线程。。。
Sidechannel defences: Why?
侧通道防御：为什么？
For a modern cryptographic scheme to be taken seriously, we generally require some form of security justification. In the case of AES, we believe it acts like a random permutation if the adversary doesn't know the key. However, if the adversary has side-channel information, it is possible that this is no longer the case. So, what can we do about it? Ideally we would create an implementation that is completely impervious to side-channel attacks. However, this effectively means the implementation must sit in total isolation, with absolutely no output streams - which makes it rather pointless!
为了认真对待现代密码方案，我们通常需要某种形式的安全理由。在AES的情况下，我们认为如果对手不知道密钥，它就像一个随机排列。然而，如果对手拥有侧信道信息，则可能不再是这种情况。那么，我们能做些什么呢？理想情况下，我们将创建一个完全不受侧通道攻击影响的实现。然而，这实际上意味着实现必须完全隔离，绝对没有输出流——这让它变得毫无意义！
Perhaps we can make sure that whatever we do, it doesn't matter if the AES implementation leaks information through side channels? This leads to the field of leakage resilient cryptography, which is a very strong security requirement indeed. As such, schemes secure in these conditions (of which there are very few) tend to be drastically less efficient than those which avoid (/ignore) the problem. Since trade-offs must always be made in design, in practice we tend to use schemes that assume AES doesn't leak any information, and combine them with implementations that contain defences against some of the simpler side-channel attacks. The hope is that this pushes the attack cost beyond the value of the information secured and so (even though they could) no adversary will bother attacking the system because it is no longer viable.
也许我们可以确保，无论我们做什么，AES实现是否通过侧通道泄露信息都无关紧要？这导致了泄漏弹性密码学领域，这确实是一个非常强的安全要求。因此，在这些条件下安全的方案（很少）往往比那些避免（/忽略）问题的方案效率低得多。由于在设计中必须始终进行权衡，因此在实践中，我们倾向于使用假设AES不会泄露任何信息的方案，并将其与包含防御一些更简单的侧信道攻击的实现相结合。希望这能将攻击成本推高到安全信息的价值之外，因此（即使他们可以）没有对手会因为系统不再可行而麻烦攻击系统。
Some Basic Defences 一些基本抗辩
So, with that in mind, let us consider a couple of basic defences against some of the less sophisticated side-channel attacks. As pointed out in the question, these techniques may be easily bypassed, so think of this post as explaining the general concept, rather than providing any sensible suggestions!
因此，考虑到这一点，让我们考虑一些基本的防御措施，以对抗一些不太复杂的侧通道攻击。正如问题中所指出的，这些技术可能很容易被绕过，所以把这篇文章看作是解释一般概念，而不是提供任何明智的建议！
Attack: Timing Attack 攻击：定时攻击
Weakness: Some implementations run in different times depending on their inputs. As such, by observing how long the system takes to respond one learns something about the key/inputs.
弱点：一些实现根据其输入在不同的时间运行。因此，通过观察系统需要多长时间才能做出响应，人们可以了解一些关于按键/输入的信息。
Defence: Constant time implementations. As the title says, the best defence against a timing attack is to make sure the implementation takes constant time, and most implementations will be
防御：持续时间实施。正如标题所说，对定时攻击的最佳防御是确保实现需要持续的时间，而大多数实现都是 constant-time nowadays. This might not be too hard in hardware, but in software it can be very difficult indeed, because the microcode (the internal programming of the processor) is generally a trade secret and open to change.
现在时间不变。这在硬件上可能不太难，但在软件上可能确实非常困难，因为微码（处理器的内部编程）通常是商业秘密，可以更改。
Attack: Power Analysis (DPA,SPA)
攻击：功率分析（DPA，SPA）
Weakness: The power usage of some implementations is correlated with the key material, often due to the hamming distance when storing values. For more information, read the blog from two weeks ago.
弱点：一些实现的功耗与关键材料相关，通常是由于存储值时的汉明距离。欲了解更多信息，请阅读两周前的博客。
Defence (1): Masking Rather than using the AES Sbox directly, one applies a mask to the input value, and looks this up in a masked Sbox (which is effectively the Sbox with its values reordered to accommodate the mask). Then, even though the attacker may be able to detect correlations between certain internal variables, these are all masked, and do not [directly] correspond to the key material as they had previously. More complex masking schemes will be more complex to instantiate, but lead to better resistance to attack.
防御（1）：掩码不是直接使用AES Sbox，而是将掩码应用于输入值，并在掩码Sbox中查找它（实际上是对其值进行重新排序以适应掩码的Sbox）。然后，即使攻击者能够检测到某些内部变量之间的相关性，这些变量都被掩盖了，并且不像以前那样[直接]对应于关键材料。更复杂的掩蔽方案实例化起来会更复杂，但会更好地抵抗攻击。
Defence (2): Shuffling To conduct a power analysis attack, the attacker uses the fact they know the internal structure of the AES scheme. If we shuffle the order of the S-boxes in our implementation (by some secret permutation), the adversary will not know how their readings correspond to the internal key materials. A variation on this is the deliberate use of non-determinism, allowing the processor to reorder certain collections of instructions on it's own.
防御（2）：洗牌为了进行功率分析攻击，攻击者利用他们知道AES方案的内部结构的事实。如果我们在实现中打乱S盒的顺序（通过一些秘密排列），对手将不知道它们的读数如何与内部密钥材料相对应。对此的一个变体是故意使用非确定性，允许处理器自行重新排序某些指令集合。
Attack: Cache-flooding 攻击：缓存泛滥
Weakness: Implementations using lookup-tables (eg for the SBox) will be more or less efficient if the appropriate cells are already in the processors cache. By pushing most of the lookup table out of the cache, an attacker can observe whether the appropriate cells are called, leaking information. Can also be observed as a timing attack or by power analysis if the cost of loading the cache can be observed.
弱点：如果适当的单元已经在处理器缓存中，那么使用查找表（例如SBox）的实现或多或少会有效率。通过将大部分查找表从缓存中推出，攻击者可以观察是否调用了相应的单元格，从而泄露信息。如果可以观察到加载高速缓存的成本，也可以观察到定时攻击或通过功率分析。
Defence: Dont use lookup tables on secret data! The simplest defence in this list - if you don't want to leak information about which lookup entries have been used, don't use lookup tables. In the case of AES this is reasonable, because the AES Sbox can actually be computed as a simple function on the input byte. This would be much less practical with (for example) the DES Sbox, which does not have this structure.
防御：不要在秘密数据上使用查找表！这个列表中最简单的防御措施是——如果你不想泄露关于使用了哪些查找条目的信息，就不要使用查找表。在AES的情况下，这是合理的，因为AES Sbox实际上可以作为输入字节上的简单函数来计算。这对于（例如）没有这种结构的DES Sbox来说将不太实用。
The Working Class Must Lead！
