伽利略提出的认证算法：第一部分

位置、速度和时间(PVT)信息可能是“值得拥有的”信息，但在其他情况下，知道地点和时间也具有法律或军事重要性。例如，重型车辆通常配备有跟踪司机速度和/或位置的转速仪。这对休息规则很重要，但也要检查负载是否真的来自他们所说的地方。

到目前为止，我们的全球导航卫星系统正在广播未经认证的数据，至少是向民用用户广播。或者换句话说，是卫星向我们发送信息，但我们无法确定这些信息是否真的来自GPS、GLONASS、伽利略或北斗。

PVT欺骗(预防)的主题是广泛的，问题是真实的。没有简单的解决方案，而且很容易陷入为任何改进建议寻找缺点的泥潭中。

不过，给GNSS消息添加认证和完整性肯定是任何解决方案的一部分，但应该认识到，卫星并不是直接向我们发送我们的位置。他们正在向我们发送数据，让我们可以确定我们的位置、速度和时间。即使所有消息都具有完美的完整性，经验丰富的攻击者也可以使用RF术让接收者认为它在某个地方(或某个时候！)。不然的话。

然而，能够信任我们收到的消息是非常重要的一步。伽利略将很快在这方面率先启用开放服务网络消息认证(OSNMA)。

在这篇文章(这是系列文章的第1部分)中，我希望解释一下为OSNMA提出的非常有趣的密码技术(“Timed Efficient Stream Lost-TolerantAuthentication”，又名“Tesla”)。

为了便于理解，我只关注常用的伽利略模式。此外，我还将介绍足够多的密码学来深入了解事物是如何工作的，但是我很乐意参考RFC4082和Galileo草案OSNMA规范来了解全部细节。

在本第1部分中，对GalileosSpecific BITS进行了一些重要的简化，但请放心，在第2部分中，我们将深入了解实际实现的细节。在第3部分中，我们将解决实际的棘手领域(如键翻转)，也许还会解决未解决的问题。最后，第4部分将涉及GNSS欺骗和干扰的一般性问题。

但在我们开始之前，我需要感谢在我把帖子放到网上之前自愿阅读我帖子草稿的许多人。如果这些帖子看起来很专业或消息灵通，这在很大程度上是因为Twitter朋友、Galileo IRC(聊天)频道或愿意向我提供专业知识的未具名伽利略专业人士的帮助。谢谢!。

伽利略卫星每两秒恰好发出一次信息。许多这样的消息实际上会丢失(“丢包”)，但没关系，它们是每30秒重复一次的传送带的一部分，并不是所有的消息都需要PVT。对于伽利略来说，一组消息通常会轮换10分钟左右，然后被一组新的消息所取代。每颗卫星都有自己独特的一组信息。

1：原子钟超前1.234 ns，漂移12 ps/s2：轨道半径为22000 km，偏心率为1.000034，...3：完整的轨道参数4：还有更多的轨道参数5：伽利略周数，闰秒数，自周日以来的秒数6：关于机队中其他卫星的消息7：关于其他卫星的更多消息8：关于电离层的信息9：NOP...。

对于伽利略来说，每条消息的内容大小为128位。此外，还有24个CRC比特，另外还有用于搜索和救援数据的比特，一些开销，加上40+8+2比特的预留空间，每条报文总共240比特。我们在认证方面所做的任何事情都必须放在预留空间中。

现在，获得身份验证的天真方法是使用公钥加密，并对每条消息单独签名。这个想法的一个问题是，现代接收器同时收听多颗卫星，而且还在多个频段上收听。接收机每秒需要验证20个签名是完全可能的。

这就是我们遇到的第一个问题--许多接收器中的嵌入式CPU将很难执行那么多的公钥密码术。他们也可能使用比我们希望的更多的电池电量。

此外，即使是最小的椭圆曲线数字签名也只有数百比特-而卫星射频信道上根本没有那么大的可用空间-我们只有大约40比特(每条消息)。整个导航消息本身比典型的ECDSA签名要小！

我们能聪明点吗？或者拿整个消息传送带，在整个集合上浪费一次公共密码操作？我们可以，但由于个别消息经常丢失，这实际上会使验证变得不可能-完整的15条消息毫发无损的情况很少见。

当然，我们可以为每条消息添加一个简单的MAC签名。要验证MAC，接收方需要知道(对称！)。这是可行的，但也很糟糕-如果接收器拥有该密钥(用于验证目的)，它可以简单地模拟整个卫星系统！在进行“对称认证”时，验证密钥和签名密钥是相同的。

尽管如此，这就是提议的内容，但有一个转折。每条单独的消息都带有一个指示符，指示它是由哪个密钥ID签名的，外加一个用该密钥制作的MAC。

这里有一个转折：只有在收到消息后才会发送密钥。

为此，接收方保留(但不使用)其接收到的消息，直到发出相关密钥，并且可以验证数据接收方实际上是正确签名的。

这引入了一个不对称的元素--起初，只有发送者有权访问密钥，并且只有发送者可以生成签名。公开后，接收者可以验证他们在密钥共享之前收到的任何消息的真实性。

(如果这一点还不完全清楚，我们将在下一节中进行简要介绍)。

现在，这是相当聪明的，但是有很多问题。比如，我们刚收到的钥匙是怎么生锈的？

到目前为止，我们知道如果我们认为我们收到的最新密钥是可信的，我们可以验证之前消息上的签名，并向后扩展信任。

...消息2用密钥ID 5签名消息3用密钥ID 5签名消息4用密钥ID 5签名...消息15用密钥ID 5签名消息1：密钥5是0x23543542343消息2，用密钥ID 6签名消息3，用密钥ID 6签名。

在此序列之后，我们可以验证所有用密钥5签名的消息，并且可以像信任密钥5一样信任它们，也就是说，完全不信任。

(请注意，在现实中，整个新密钥不会突然出现在一条消息中-请继续关注本系列的第2部分，了解它的真正工作原理)。

这就是它变得聪明的地方。每隔一段时间，伽利略就会发出一个带有真正公钥签名的密钥。“伽利略公钥”被广泛发布，所以我们知道我们可以信任它。不过，我们不能经常进行这样的公钥签名--没有足够的带宽、CPU和电池电源可用。但每隔一段时间我们就能做到。

好的，所以一旦我们验证了公钥签名，我们就可以信任(比方说)密钥id0。这很好，但是它不会影响我们对密钥id5的信任。我们需要的是信任链。

要创建这样的链，实际上需要使用“NEXT”键作为输入来生成密钥。非常简单(并且不正确)，密钥ID5排序为密钥ID6的散列，密钥ID4可以从密钥ID5导出，依此类推。

换句话说，如果您知道密钥6，则可以派生密钥5、4、3、2、1，最终派生为0。然后您可以使用realpublic key签名检查密钥0的有效性！

因此，要验证消息，接收方需要等待，直到它看到消息用来签名的密钥。如果这是密钥id 6，它还将计算密钥5、4、3、2、1和0。然后，它将检查密钥ID 0的真实公钥签名是否为ISON文件。如果所有这些都匹配，我们可能会决定信任用这些密钥签名的信息。

通过使用短暂保密的密钥对消息进行签名，并在延迟一段时间后将其公开，接收方可以验证以前的消息是否使用该密钥正确签名。

密钥是通过将它们设计成链来生成的，以便每个密钥都可以用来派生前一个密钥。有时，伽利略使用实际的公钥密码术对密钥进行签名，通过向后推理，我们可以验证每个密钥都源于原始签名的“锚”。

使用这两种技术，确实可以创建小的对称签名，但仍然可以实现消息身份验证。

现在，就像所有的密码学一样，细节很重要。非常重要的一点是，接收方不使用传输的密钥来验证稍后传入的消息。

在特斯拉中，有一些重要的选择需要算法来支持签名、密钥派生和公钥操作。此外，还必须选择密钥链的长度和使用Akey的时间长度。例如，如果该时间太长，则接收器将在处理数据时滞后。

此外，当然非常清楚的是，OSNMA只有在接收器和发射器就时间达成一致的情况下才能工作。对TELA的许多攻击都围绕着这个问题。

请继续关注这篇文章的第二部分，在那里我将深入研究为特斯拉协议做出了哪些特定于伽利略的选择，以及密钥实际上是如何分发的。同时，非常欢迎您在[email protected]或通过Twitter@GalileoSats提出建议、更正和问题。