扩展大型移动系统的假名认证
目录
摘要
安全和保护隐私的车载通信（VC）系统的核心组成部分是车载公钥基础设施（VPKI），提供给车辆多个假名。这些假名被用来在保护车辆隐私的同时确保消息的真实性和完整性。鉴于新兴的大型多域VC环境，VPKI的效率以及可伸缩性至关重要。同样，防止假名的滥用，尤其是基于Sybil的行为不当，以及管理“诚实而又好奇”的内部人员，也是面临挑战的其他方面。在本文中，我们利用了最先进的VPKI系统，并增强了其功能，以实现高可用性，动态可扩展和弹性设计。 这确保了系统在出现良性错误或资源耗尽攻击的时候保持可用性，并且它根据请求到达的速率动态向内或向外扩展。我们在谷歌云平台上的全面实现表明，部署大规模和高效的VPKI是经济有效的。
1.介绍
vehicles beacon Cooperative Awareness Messages (CAMs)车辆信标协同感知信息
Decentralized Environmental Notification Messages (DENMs)分布式环境通知信息
在VC系统中，定期高速率的车辆信标协同感知信息和分布式环境通知信息使得交通安全和有效。
众所周知，VC系统很容易遭受攻击并且用户的隐私受到威胁。
安全和隐私的解决方案也被众多组织提出。
一种共识被达成，即使用公钥加密（PKC）去保护V2V、V2I的通信：一组短期的匿名证书，称为假名，由车辆公共密钥基础设施（VPKI）为已经注册过的车辆颁发。
车辆从一个假名切换到一个以前没有使用过的假名，以实现消息不可链接性，因为假名本身就是不可链接的。假名是有条件的，从某种意义上说，相应的长期车辆身份可以在需要时由VPKI检索，例如：如果车辆偏离了系统政策。
Certificate Revocation List (CRL)证书撤销列表
车辆能够请求长期的假名，但是，长时间每辆车以数百万个假名的大量预加载在计算上成本高昂，并且在利用方面效率低下。并且，在撤销的情况下，由于证书的长寿命一个大的证书撤销列表会被分发给所有的车辆，但是CRL的相当一部分与接收车辆无关，可以不使用，这就导致浪费了很大的带宽用于CRL分发。或者，每个车辆可以与VPKI定期进行交互，例如，一天一次或几次，不仅仅是为了填满它的假名池，而且获取最新的撤销信息。然而，在遭受阻塞式拒绝服务攻击的时候VPKI系统的性能会急剧下降，这样就损害了VPKI实体的可用性。并且，高峰时段假名获取请求的激增，可能使VPKI无法访问，或大大降低其服务质量（flash crowd）。
VPKI不可用的代价是双重的：安全（道路安全恶化）和隐私。一个活跃的恶意实体可以阻止其他车辆访问VPKI来获取最新的吊销信息。此外，使用对应于过期假名或长期证书（LTC）的私钥对CAM进行签名是不安全的，并且不利于用户隐私。
虽然可以依靠匿名身份验证原语来重新填充假名池，但与安全相关的应用程序的性能可能会降低。对大多数车辆使用匿名身份验证方案会导致验证CAMs所需的加密处理开销增加30%,因此，必须提供高可用性、可伸缩和弹性的VPKI设计，以按需方式有效地颁发假名。
考虑到VC系统朝着多域方向的发展，随着多域中服务提供者的多样性，每辆车都可以从不同的服务提供商处获得假名。获得多个同时有效的假名将使敌人能够注入多个错误消息，例如危险通知，仿佛它们来自多个车辆，或者通过发送虚假但经过认证的信息来影响基于投票的协议。尽管有分布式的方案来识别女巫节点，或者依靠硬件安全模块（HSMs）来缓解脆弱性，但是一个VPKI系统应该在基础设施端防止这种凭据滥用。然而当在云端部署这样的一个系统的时候，一个恶意的车辆能够重复请求假名，实际上，请求可能被传递到微服务的不同副本，发放多个同时有效的假名。要求所有副本共享一个集中的数据库，以确保所有事务的隔离和一致性，这将减轻此类漏洞。然而，这与为大规模移动系统提供高效和及时的假名是矛盾的。
贡献：在这篇论文中，我们利用并并加强了VPKI，并且提出了VPKI即服务的系统，朝着高可用性、动态扩展性、和容错性（高弹性）设计的方向，确保系统在出现良性错误或任何的资源耗尽攻击时的可用性。此外，我们的方案消除了在云上部署带有多个微服务副本的系统时基于sybil的不当行为，而不会降低假名获取效率。部署和迁移到云的所有过程，例如，引导阶段、微服务的初始化、假名获取过程、运行状况监控和负载指标等都是完全自动化的。通过大量的实验评估，我们表明VPKIaaS系统可以根据VPKIaaS系统的工作负载和请求到达率动态地向外扩展，或者可能向内扩展，以至于它可以轻松地处理意外的高要求负载，同时通过系统地分配和释放资源来实现成本效益。我们的实验评估显示了36倍的改进比以前的工作：之前的系统发出100个假名的处理延迟大约是2010毫秒，而我们的系统大约是56毫秒。此外，当假名请求到达率激增时，原来系统的性能会急剧下降，相反，我们的VPKIaaS系统可以轻松地处理苛刻的负载请求，同时有效地颁发假名。
2.背景和相关工作
VPKI可以长时间（例如25年）为车辆提供有效的假名。然而，如此长的一段时间内，每辆车都要使用数百万个假名，这在计算上是昂贵的，效率低下的，撤销起来也很麻烦。相反，一些提议建议更频繁的车辆与VPKI的交互，即随需应变方案。这种策略提供了更有效的假名使用和撤销，从而有效地防止了不当行为。但是，对于按需获取假名，需要设计(和部署)一个有效的、可扩展的系统，同时能够抵抗任何资源消耗攻击。尽管VPKI系统可以处理大规模的分布式场景，但是缺乏动态可伸缩性(例如，根据到达率动态地向外/向内扩展)和对资源消耗攻击的弹性（容错性）。除了显著的性能改进之外，我们的VPKIaaS实现是高可用性的、动态可扩展的和容错的。基于sybil的不当行为会严重影响VC系统的运行，多个伪造的不存在的车辆会通过注入虚假信息污染网络。例如，具有多个有效假名的对手(此处称为Sybil节点)可能会产生一种影响流量监控系统运行的流量拥塞假象，或者广播虚假的不当行为检测投票，或者在社交网络中向其他用户发送垃圾邮件。强制不重叠的假名生存期的主意第一次被提出，这样可以防止对手为自己配备多个有效身份，从而影响收集多个输入的协议，例如：基于投票的，通过发送冗余的虚假但已被证实的信息。即使这个想法已经被接受，很多提议例如[63,88]，并不能阻止车辆通过多个假名请求同时获得有效的假名。多个假名发行者的存在恶化了这种情况：车辆可以向多个服务提供者请求假名，而每个服务提供者都不知道同一时期的假名是否由其他服务提供者提供了。人们可以通过依赖HSM来减轻这个漏洞，确保所有签名在任何时候都在一个有效的假名下生成。也有基于无线电特性和三角测量的分布式Sybil节点检测方案；这种策略依赖于应用程序，例如，这不能保证流量监控系统的运行，因为对手传播多个流量拥塞消息，每个消息都在一个不同的“假”私钥下签名。v -令牌[81]阻止一个车辆获得多个同时有效的假名，因为有服务提供者彼此通信，例如，一个分布式哈希表。SECMACE[60](包括它的前身[54,55])可以防止基础设施端基于sybil的不当行为，而不需要额外的实体，即例如，额外的交互或VPKI内部通信。更具体地说，它确保在多域环境中的任何时候，每个车辆都有一个有效的假名。然而，当在云上部署这样一个系统时，恶意车辆可以重复请求假名，希望请求被发送到微服务的不同副本，从而获得多个同时有效的假名。与这些方案不同，我们的VPKIaaS方案可以防止在云部署的基础设施上基于sybil的不当行为：它确保了在一个多域内的任何时候，每个车辆只能有一个有效的假名；更重要的是，这并不影响假名的及时发放。
VPKI实体通常被隐式地假定为完全可信的。考虑到最近移动应用的经验，对手模型从完全可信扩展到诚实但好奇的VPKI服务器，如果这些诚实但好奇的实体在没有被发现的情况下获得优势，则可能会破坏安全协议并偏离系统策略，例如：推断用户敏感信息。在VC领域之外，有各种不同的提议为PKI来抵御恶意的内部人员，这种方案依赖于超过阈值数量的CA签署证书；但是，这些方案不能被VC系统使用。例如，颁发证书大约需要2分钟，并且它随所需CAs的数量而变化，显然，这与VC系统按需获取假名的策略是矛盾的。
3.系统模型和目标
3.1概述和假设
VPKI由一组具有不同角色的证书颁发机构(CAs)组成：根CA (RCA)，拥有*别的权限，认证其他较低级别的权威机构；长期CA（LTCA）负责车辆注册和长期证书（LTC）签发，假名CA（PCA）为已注册的车辆发布假名。
假名有一个生命周期(有效期)，通常从几分钟到几小时不等；理论上，假名寿命越短，不可链接性越高，隐私保护程度也就越高。我们假设每辆车只在其Home-LTCA (H-LTCA)上注册，该Home-LTCA是策略决策和执行点，注册的车辆可以到达。在不丧失一般性的情况下，可以将域定义为在H-LTCA注册的区域内的一组车辆，并遵守相同的行政法规和政策。可以有多个PCA，每个PCA在一个或多个域中处于活动状态；任何合法的，即已注册的车辆都可以从任何PCA(假名提供者)获得假名(只要两个CAs之间建立了信任关系)。两个域之间的信任可以在RCA的帮助下建立，或者通过交叉认证建立。
每个车辆与VPKI实体进行交互，以获得一批假名，每个假名具有相应的短期私钥，以对它们的移动性信息（例如CAM或DENM）进行签名和分发，并定期或在需要时进行时间和地理标记作为对特定事件的响应。在域A注册的车辆使用私钥ki v对发出的消息进行数字签名，该私钥与Pvi对应，Pvi表示由PCA签名的当前有效假名，然后将该假名附加到已签名的消息中，以允许任何收件人进行验证。接收到消息后，在验证消息本身之前先对假名进行验证(签名验证)，此过程确保通信真实性、消息完整性和不可否认性。车辆从一个假名切换到另一个假名(以前没有使用过)来实现不可链接性，从而保护发送者的隐私，因为假名本身是不可链接的。
每个车辆根据各种因素“决定”何时触发获取假名的过程。这种方案需要与VPKI的稀疏连接，但它有助于车载单元（OBU）预先加载假名，覆盖时间更长，例如，一个星期或一个月，连接可能会严重间断。H-LTCA指定了一个通用的固定间隔Γ，并且该域中的所有假名均以与VPKI时钟对齐的生存期（τP）发出，由于该政策，所有车辆在任何时间点都使用假名进行传输，由于时间对齐，这些假名无法根据其发布时间进行区分。
所有注册的车辆(OBUs)都配备了HSMs，确保私钥不会离开HSM。此外，我们假设存在一个不当行为检测系统，可以触发吊销。解决机构(RA)可以发起一个进程来解决和撤销行为不端的车辆的所有假名：它与相应的PCA和LTCA进行交互，以解决和撤销针对行为异常的车辆发出的所有凭据。结果，行为不端的车辆不再能从VPKI获得凭据。VPKI负责分发CRLs并通知所有合法实体撤销。我们进一步假设云服务提供商是诚实的，他们提供的服务具有所需的服务水平协议：在保密管理方面，我们假设云服务提供商是完全可信的。
3.2对手模型和要求
我们扩展了安全车载通信中的一般对手模型，以包括诚实但好奇的服务提供商，即一个试图为了达到自己的目的获取优势的PCA，例如,分析用户。此外，在这项工作的背景下，恶意PCA可能会尝试（i）为合法车辆颁发多组（同时有效）假名，或(ii)为不存在的(非法的)车辆发放一套假名，或者(iii)在假名解析过程中欺骗不同的车辆(用户)。一个不正常的LTCA可能试图在解析过程中映射一个不同的LTC，从而误导系统。在我们的对手模型中，我们假设LTCA没有违规注册非法车辆，例如，发行虚假的LTCs，但可能会试图发行假授权票证，以在假名获取过程中使用。RA还可以不断地发起假名验证过程，以推断用户敏感信息。我们的对抗模型考虑多个VPKI服务器串通，即分享他们各自推断出的信息，从而损害用户的隐私。
在多PCA环境中，恶意客户端会带来两个挑战。第一，他们可以重复请求多个同时有效的假名，从而将每个假名当作多个注册的看上去合法的车辆，第二，它们可以通过对VPKI服务器进行阻塞的DoS攻击来降低系统的操作。外部对手，例如，未经授权的实体，可能试图通过发起DoS(或DDoS)攻击来破坏系统操作，从而降低系统的可用性。但是他们无法成功伪造消息或“破解”所采用的密码系统和密码原语。
对V2X通信的安全性和隐私要求已在[70]中得到了广泛指定，在[60]中对VPKI实体以及在[57]中对CRL进行了其他要求。除了上述要求之外，在云上部署VPKIaaS系统时，我们需要在不降低假名发放效率的情况下阻止基于Sybil的攻击。同时，我们需要确保VPKIaaS系统是高可用性和动态可扩展的：系统根据请求的到达率动态地向外扩展或可能向内扩展，以处理任何需要的负载，同时通过系统地分配和释放资源实现成本效益。此外，我们需要确保该方案对任何资源消耗攻击都具有弹性。
4.VPKI服务概述和安全协议
在注册阶段，每个H-LTCA注册其域内的车辆并保持其长期身份。在引导阶段，每个车辆都需要发现与vpki相关的信息，例如，其本地域中的可用PCA或外部域中所需的Foreign-LTCA（F-LTCA）和PCA，以及它们相应的证书。为了促进整个域内和多域操作，车辆首先从轻型目录访问协议（LDAP）服务器中找到此类信息。这是在不披露车辆真实身份的情况下进行的。我们假定与VPKI的连接，例如通过路边设备(RSUs)或cellar - v2x；我们假定通过路边单元（RSU）或Cellular-V2X与VPKI建立连接； 如果连通是间歇性的，则车辆（即OBU）可以根据不同的参数（例如，剩余有效假名的数量，剩余行程持续时间和网络连接性）主动启动假名供应。
LTCA通过相互验证的传输层安全（TLS）隧道对车辆进行身份验证和授权。这样，车辆便从其H-LTCA获取了本地票证（n-tkt），而目标PCA或实际假名获取期却对H-LTCA隐藏了；这个票据是匿名的，它不会显示其主人的身份。然后，通过单向（仅服务器）认证的TLS将票证提供给预期的PCA，以获得假名。
车辆在外域行驶时，应从在该域区运行的PCA获得新的假名；否则，车辆将脱颖而出，并且更易于追踪（可链接）。车辆首先从其H-LTCA请求外部票据（f -tkt）（而不会透露其目标F-LTCA），以便可以由F-LTCA进行身份验证和授权。反过来，F-LTCA为车辆提供一个新的票据(n-tkt)，它是F-LTCA域内的本地票据，用于在该(外部)域内获取假名。然后，车辆与其所需的PCA交互以获得假名。获得外部票据f -tkt对H-LTCA是透明的：H-LTCA无法区分本地和外部票证请求。这样，外部域中的PCA无法将本地请求者与外部请求者区分开。在责任归属方面，我们的方案在PCA和LTCA的帮助下，启用RA去启动一个撤销进程，例如，撤销一个假名的长期身份。每一辆车都可以与本地或外域中的任何PCA交互，以获取CRL并执行在线证书状态协议(OCSP)操作，使用当前有效的假名进行身份验证。
4.1VPKI即服务
我们将VPKI迁移到谷歌云平台(GCP)上，以了解VPKI系统在各种情况下的可用性、可靠性和动态可伸缩性。图2说明了GCP上托管Kubernetes集群[25]上VPKIaaS架构的高层抽象。将根据其相应的容器映像为每个微服务（例如LTCA或PCA）创建一组Pod，以促进其水平可伸缩性。当假名请求的比率增加时，Kubernetes主服务器（如图2顶部所示）会安排新的Pod或杀死运行中的Pod，以防发生良性故障（例如系统故障或崩溃或资源耗尽攻击），例如 DoS攻击。Pods可以扩展到部署配置中设置的数量，或者扩展到Kubernetes节点启用的可用资源数量。
每个Pod都会发布两种类型的指标：负载和运行状况。负载度量值由资源监视服务生成，这有助于微服务的水平扩展：当达到预定义负载的阈值时，复制控制器将复制微服务的一个新实例，以确保获得所需的服务水平SLA。运行状况指标通过持续监视微服务的状态来确保微服务的正确操作：一个有故障的Pod被杀死，并创建一个新Pod。在我们的VPKIaaS系统中，我们将CPU使用率定义为负载指标。为了监视微服务的运行状况，每个Pod将在本地查询虚假请求(LTCA微服务的虚假票证和PCA微服务的虚假假名)。
4.2安全协议
在本节中，我们提供了假名获取过程(协议1)和假名发放验证过程(协议2)的详细描述，以识别行为不当的PCA发放假冒假名。此外，为了减轻VPKIaaS系统受到的Sybil攻击，我们提出了两个协议(协议3和4)：一个在内存中的键值Redis数据库[14]被共享在微服务的所有副本中，以促进票据和假名请求的有效验证。表1显示了安全协议中使用的符号。
4.2.1假名获取过程（协议1）
每辆车首先向它的H-LTCA请求一张匿名票据，用它与期望的PCA交互以获得假名：由于篇幅有限，我们在附录中提供了详细的票据获取流程。在收到有效票据后，它就会使用椭圆曲线数字签名算法(ECDSA)公/私钥对生成证书签名请求(CSRs)，并将请求发送给PCA。Vehicle-LTCA通信通过相互认证的TLS 隧道（或数据报TLS（DTLS）），而Vehicle-PCA通信通过单向（仅服务器）认证的TLS（或DTLS）进行；这确保了PCA不会推断出请求者的实际身份。
收到请求后，PCA验证由H-LTCA签名的票据（假设在两者之间建立了信任）（步骤1.2–1.3）。然后，PCA将票证解封装并验证假名提供者身份（步骤1.4–1.5）。然后，PCA生成一个随机数（步骤1.6）并启动所有权证明协议，以验证车辆对相应私钥的所有权（步骤1.9）。然后，它计算”可识别的密钥”，（步骤1.10）.这从本质上防止了一个恶意的PCA在解析过程中映射不同的票据，或者在没有收到有效票据而发出假名的情况下识别出一个恶意的PCA。PCA隐式地关联属于每个请求者的一批假名(步骤1.11-1.15)。
4.2.2假名签发验证过程（协议2）
在接收到识别错误行为的请求后，例如向流量监控系统发送多个可疑流量拥塞警报，实体可以向RA发送请求，以验证一个“可疑”假名的假名发放过程(步骤2.1 - 2.4)。RA验证请求并与签发假名的相应PCA交互，为假名签发过程提供证据；事实上，这一过程确保了一辆真实的车辆通过提供有效的票据请求使用假名，也保证了PCA不会为一辆非法车辆提供假名(步骤2.5 - 2.8)。收到请求后，PCA会验证请求，并提供相应的票证和用于发布假名的RndIKPiv。回应由PCA签名返回给RA。收到响应后，RA将对其进行验证，促进使用LTCA的公钥来验证票据。并且检查
如果哈希计算的结果是相同的哈希值，那么它确认假名是基于有效票证发出的，即由LTCA适当地发行。此外，它确保PCA不会为一辆不存在的车辆发出假名。注意，在执行假名签发验证过程中，车辆的实际身份是不公开的，也就是说，用户隐私受到了很强的保护。
4.3减轻对VPKIaaS的Sybil攻击
微服务的多个副本与相同的数据库交互，以完成它们的操作，例如LTCA的所有副本都应该与同一个数据库进行交互来存储它们签发的票据的信息。同样，所有的PCA副本都与单个数据库交互，以验证授权票据并存储与所颁发的假名对应的信息。微服务可以选择同步或异步地使用它们共享的MySQL数据库。微服务和共享数据库的异步交互将导致有效的假名发布。然而，恶意车辆可以重复提交请求。如果微服务不同步地验证票据和假名请求，那么如果请求被传递到不同的副本，则一个车辆可以获得多组假名。另一方面，微服务和共享数据库的同步交互将防止为给定的请求者发出多组假名，从而根除基于sybil的不当行为。然而，这将大大降低系统的性能，特别是在及时按需发行假名。使用的关系数据库MySQL的性能会因为同步交互而大大降低。此外，向外扩展Pods以处理大量的工作负载，同时依赖于一个共享的MySQL数据库会成为单点故障，这就质疑了这种方案的实用性(高可用性和动态可伸缩)。
为了系统地缓解上述漏洞，我们提出了一个混合设计，通过考虑两个独立的数据库。图3显示了VPKIaaS的内存存储:一个作为与Redis[14]协议兼容的GCP服务的内存键值数据库和一个关系数据库，例如,MySQL。
微服务的每一个Pod与Redis数据库同步交互，以验证一个请求，以阻止Sybil攻击。验证请求后，将发出票据和假名，并将相应的信息异步地存储在关系数据库中。这样的混合设计在不降低假名获取过程的总体性能的情况下减轻了Sybil攻击：通过关系型数据库进行的耗时验证被通过Redis数据库进行的有效验证所取代。
4.3.1 对LTCA的Sybil攻击缓解（协议3）
LTCA，是域中的策略决策和实施点，以不重叠的时间间隔发行票据，即，车辆不能获得寿命重叠的票据。在收到票证请求时，每个LTCA微服务Pod应该检查在此期间是否向请求者发出了票据。强制执行这样的政策，确保没有车辆将获得一个以上的有效票据，为了请求多个同时有效的假名。此外，每个票据被车辆隐式地绑定到一个特定的PCA；;因此，该票据不能使用超过一次或用于其他PCAs。每个LTCA微服务Pod在Redis数据库中存储车辆LTC的序列号(作为键)和当前票据的过期时间(作为值)。在收到获取票据的新请求时，每个微服务创建一个Redis管道来验证票据(步骤3.2)。一个Redis管道需要一个命令列表，保证按顺序执行而不中断。
Redis管道检查数据库中LTC的序列号是否存在；如果存在，它验证请求间隔是否与先前记录的条目重叠(步骤3.3);如果数据库中存在序列号，且请求的票证开始时间(tktst art)小于已存在的票证的过期时间，则请求被标记为恶意。否则，Redis管道将使用新的票据到期时间更新相应的条目(或者添加一个新的条目(如果不存在))(步骤3.4)。然后，将调用票证发行程序（步骤3.5，即附录中的协议6）。如果在票据签发过程中出现任何故障，票据到期值将回滚(步骤3.6-3.8)。Redis管道在单个线程上执行，保证顺序执行命令;因此，即使LTCA的所有副本都收到来自同一车辆的票据请求，Redis确保只有一个票据请求将被服务，其余的将被拒绝。
4.3.2对PCA的Sybil攻击缓解（协议4）
PCA发行具有不重叠寿命的假名，以确保在任何给定时间点不为车辆提供一个以上的有效假名。然而，为了完全根除基于sybila的不当行为，PCA微服务应该确保每个票证只用于为请求者发出一组假名。换句话说，VPKIaaS系统应该确保PCA微服务的不同副本不会为一张票据发出超过一组假名。PCA的所有副本共享一个Redis存储，其中有票据序列号(作为键)和布尔数据类型(作为值)。如果票据序列号不存在，或者如果它存在且布尔数据类型值为false，则票据未被使用。
在收到假名获取请求后，PCA微服务的每个Pod创建一个Redis管道来验证票据(步骤4.2)。如果键(SNtkt)不存在或值为false(步骤4.3)，Redis将数据库更新为true，并调用发出假名的程序(步骤4.5，即协议1)。如果在获取假名过程中失败，那么在Redis数据库中，票据对应的值将被设置为false，即回滚事务，以确保假名发放程序的一致性(步骤4.6-4.8)。如果键(SNtkt)对应的值为真，则应该拒绝获取一组假名的请求(步骤4.13)。
5.定性分析
关于VPKI实体要求的详细安全性和隐私分析可以在[57，60]中找到。在这里，我们编写了用于在云上部署VPKIaaS系统的安全和隐私分析，并讨论了这个问题的其他事实。关于云中的秘密管理的详细描述见附录。
5.1安全和隐私分析
Sybil-based不当行为：恶意车辆可能会尝试重复请求从LTCA获取多张票证，或主动从PCA请求多套假名。然而，微服务的所有副本共享一个Redis内存存储来验证每个请求。因此，任何可疑的请求都可以立即通过Redis内存存储进行验证(无需与MySQL交互，这会花费更多的时间)。Redis在单线程上执行，管道保证顺序执行命令;因此，即使微服务的所有副本（例如PCA）同时从一个车辆接收到假名请求，VPKIaaS系统也将仅服务于一个假名请求，其余的假名请求将被拒绝。因此，VPKIaaS确保了有效的票据和假名供应，同时防止任何车辆获得多个票据或假名集。Redis服务失败的后果取决于失败后采取的措施，即失败打开或失败关闭。在fail open的情况下，Sybil攻击是可能的，因为VPKIaaS系统将为车辆提供虚假的假名。稍后，它将错误发出的凭据添加到CRL中，使其无效。在fail close的情况下，VPKIaaS系统将停止发出凭据，直到故障得到解决。
或者，一个恶意的PCA可以为一个给定的车辆颁发多个同时有效的假名，或者为一个没有LTCA颁发的有效票据的实体颁发假名。但是，在执行假名验证过程时，RA请求相应的PCA验证假名。每个假名都需要有一个有效的假名可识别密钥（IK）。因此，可以识别出恶意的PCA，如果它在没有提供有效票证的情况下发出假名，就可以从VPKI系统中将其驱逐出去。请注意，在执行假名发放验证过程时，假名所有者的实际身份不会向PCA或RA披露，即，用户隐私得到保护。此外，任何实体都不能通过持续进行假名发布验证过程来推断用户敏感信息，从而损害用户隐私。我们在此强调我们的VPKIaaS方案不能阻止恶意PCA发布多组虚假的假名；相反，我们的方案以一种保护隐私的方式，通过交叉核对假名发放程序，促进了对行为不端的PCA的有效识别。为了确保微服务的正确操作，每个Pod经常请求一个虚假的票证或假名。因为这些操作是在Pod中独立执行的，所以发出的虚假的票据和假名不能离开Pod。此外，每个发布的假名可以被交叉检查，以识别可疑的恶意实体。
VPKIaaS系统上的DDoS攻击：恶意的内部实体或外部对手可能试图通过发起DoS(或DDoS)攻击来损害系统操作，从而降低系统的可用性。速率限制机制防止它们影响系统的可用性；此外，系统会标记行为不端的用户，从而将他们从系统中驱逐出去。外部对手可以通过使用假证书阻塞LTCA或使用假票据阻塞PCA来发起DDoS攻击。事实上，这些行为不端的实体试图通过要求VPKI实体过分验证假LTCs或假票据的签名来破坏VPKI实体的可用性，例如，执行签名泛洪攻击。
我们利用Kubernetes 主服务器杀死正在运行的(有问题的)Pod，从而在面对良性故障时实现高可用性和容错，例如，在系统出现故障或崩溃时，创建一个新的Pod。在资源耗尽的情况下，Kubernetes的主服务器扩展pod来处理这样高要求的负载。同时，可以采用难题技术（例如[29、33]）作为缓解方法，例如[60]：每一辆车都必须按照预先确定的顺序访问一组预定义的Pods，以解决一个难题。因此，攻击者的能力被降级为合法客户机的能力，因此，对手无法向VPKI发送高速率的虚假请求。在基础设施方面，不同的网络层有DDoS缓解技术，由不同的云服务提供商提供。
VPKI实体之间的同步：LTCA和PCA之间缺乏同步可能会影响假名发放过程，例如，PCA不会为看似“过期”的票据开具假名。但是，VPKI实体的轻微漂移时钟几乎不会影响操作，因为假名的生命周期和假名重新填充的周期通常在几分钟左右。足够让VPKI实体定期同步它们的时钟。例如，如果真实时钟(RTC)的精确度为50 parts-per-million (ppm)，即50×10^-6,并且最大可接受的错误在时间戳是50毫秒，那么每个实体应该同步其时钟每16分钟(50×10^-3s/50×10^-6 ppm)。
6.定量分析
实验装置：
指标：为了评估我们的VPKIaaS系统的性能，我们测量了在大规模移动环境中不同场景和配置下获取假名的延迟。更具体地说，我们评估带有（和不带有）flash crowd的系统的性能，以说明其高可用性，鲁棒性，可靠性和动态可扩展性。我们通过模拟大量工作负载来演示VPKIaaS系统的性能。表2显示了我们实验中使用的配置，配置1表示正常的车辆到达速率，配置2是在flash crowd场景下，实验Config-1表示每1-5秒就有一辆新车加入系统，并请求一批100-500个假名。为了模拟一个flash crowd场景，即Config-2，除了基于Config-1的车辆加入系统之外，每1-5秒就有100辆新车加入系统，并请求一批100-200个假名。
评论：假设使用不重叠的间隔发放假名(这对于减轻基于sybil的不当行为很重要)，每天获得100和500个假名意味着假名的寿命分别为14.4分钟或3分钟。根据实际的大型城市车辆移动数据集，如Tapas-Cologne[86]或LuST[40]，平均出行时间在10-30分钟内。此外，根据在美国，平均每天的通勤时间是1小时。因此，每天请求100个假名将覆盖24小时的旅行持续时间，每个假名的寿命约为15分钟。我们在这样极端的配置下评估了VPKIaaS系统的性能。
6.1大规模假名获取
图4.a说明了单张票据发行处理延迟的累积分布函数（CDF）（基于表2中的Config-1）如图示所示，99.9%的票据请求都在24毫秒内被服务。图4.b显示了用于发布假名的处理等待时间的CDF，每个请求以不同数量的假名作为参数。例如，如果每个请求都有100个假名，99.9%的车辆在不到77毫秒的时间内得到服务。即使每个请求批处理500个假名，VPKIaaS系统也可以有效地发出假名。结果表明，VPKIaaS方案是有效的，可扩展的：获取假名的过程具有较低的延迟，可以有效地向请求者发出假名。
6.2带有Flash Crowd负载模式的VPKIaaS
图5显示了VPKIaaS在获取假名请求激增时的性能(基于表2中的配置-2，图5.a中每个请求获得100个假名)。我们评估LTCA和PCA pods的CPU利用率(图5上）和每秒的假名请求总数(图5底部)。当每秒请求数增加时，平均CPU利用率将增加；但是，当CPU利用率达到水平Pod自动扩展（HPA）[24]中定义的60％阈值时，LTCA和PCA部署将水平缩放以处理苛刻的负载，因此平均CPU利用率在横向扩展时会下降。
图5.b显示了在快速拥挤flash crowd情况下获得票证和一批100或200个假名的端到端处理延迟。发出单个票据的处理延迟：99%的都能在87ms内被服务，要为每个请求发出一批100个假名，处理延迟为：99%的都能在192ms内被服务，与‘正常’条件下的处理延迟相比(图4)，发出单个票据的处理延迟从24毫秒增加到87毫秒；发出一批100个假名的处理延迟从77毫秒增加到192毫秒。因此，即使在如此高的请求速率下，VPKIaaS系统也可以有效地发行凭证。
图6a显示了每个系统组件在每个请求中获得不同批数假名的延迟时间(基于表2中的Config-2)。我们的VPKIaaS系统优于以前的工作：之前的系统发出100个假名的处理延迟大约是2010毫秒，而我们的系统大约是56毫秒。也就是说，比以前的工作有36倍的改进。图6b所示。显示了客户端观察到的获取假名的平均端到端延迟。我们可以看到，在请求激增期间，所有车辆在不到4,900毫秒(包括网络延迟)内获得了一批100个假名。显然，假名生存期越短，VPKI上的工作负载就越高，因此端到端延迟就越高。注意，在flash crowd场景下以这种速度处理请求(表2中的Config-2)意味着我们的VPKIaaS系统可以提供服务一小时内有72万辆车加入该系统。因此，即使在这样的（快速拥塞）flash crowd负载模式下，我们的VPKIaaS系统也可以轻松地处理如此高的请求需求。
6.3 VPKIaaS的动态扩展性
在这个场景中，我们将演示我们的VPKIaaS系统的性能，特别是它的可靠性和动态可伸缩性。为了模拟大量工作负载，我们使用30个容器，每个容器有1个vCPU和1GB内存(根据表2中的Config-2执行)。图7a显示了LTCA和PCA pod的平均CPU利用率(由HPA观察)以及每秒的请求总数。图7b展示了我们的VPKIaaS系统根据假名请求的速率动态向外扩展或向内扩展，箭头旁边的数字显示在任何特定的系统时间LTCA和PCA Pod副本的数量。如图所示，PCA Pods的数量从1开始，然后逐渐增加；在系统时间1500时，假名请求激增，因此PCA Pods的数量增加到80。请注意，签发票据比签发假名更有效；因此，LTCA微服务只扩展到4个Pod副本。
6.4 VPKIaaS的性能比较
我们将我们的VPKIaaS方案与基准方案[38]进行了比较，后者根据ETSI架构实现了VPKI。更准确地说，每辆车都向授权机构请求假名；该请求将转发给注册机构以检查和验证该请求。成功验证后，授权中心发出假名并将其发送回车辆。使用类似的设置进行有意义的直接比较，我们将基准方案提高了36倍的性能：在正常情况下，为基线方案发出100个假名的处理延迟大约是2010毫秒，而在我们的VPKIaaS系统中是大约56毫秒。即使在flash crowd场景下(基于Config-2)，发出100个假名的处理延迟也大约是71毫秒，即28倍的改善。此外，与[38]中的VPKI系统不同，我们的实现支持动态可伸缩性，即VPKI基于假名请求的到达率向外扩展，或者向内扩展。
此外，为了处理大量的工作负载，SECMACE[60]需要静态地将资源分配给VPKI。当到达率出现不可预测的激增或受到DDoS攻击时，SECMACE的性能将大幅下降。此外，在云上部署SECMACE时，恶意车辆可能会反复请求获取假名，以执行基于sybil的不当行为。相反，我们的VPKIaaS系统可以轻松地处理具有意外到达率的请求，同时有效地发出假名，对Sybil和资源消耗攻击具有弹性，并通过系统地分配和回收资源而具有成本效益。
7.结论
然而，它的成功需要广泛的实验评估，以确保可行性(在性能和成本方面)。我们利用最先进的VPKI，增强其功能，并将其迁移到GCP，以说明它的可用性、弹性和可伸缩性，从而实现经济有效的VPKI部署。通过广泛的安全和隐私分析，我们表明VPKIaaS系统完全根除基于sybil的不当行为且不会影响假名获取过程的效率。所有这些调查都将促进安全和隐私保护VC系统的核心构件的部署。
附录：
凭据获取程序（协议5和6）：假设车载单元OBU决定从一个特定的PCA中获取假名。它首先与它的H-LTCA进行交互以获得有效的票据。为了向LTCA隐藏它想要的PCA的实际标识，它计算特定的PCA标识与一个随机数连接的哈希值(步骤5.1-5.2)。车辆准备好请求，并在返回票证请求（步骤5.5）之前，使用与其LTC相对应的私钥对其进行签名（步骤5.3-5.4）。然后，它将通过双向认证的TLS与LTCA进行交互。在接收到票据请求时，LTCA验证LTC
(从而对请求者进行身份验证和授权)和已签名的消息(步骤6.2)。LTCA生成一个随机数(RndIKt kt)并计算“票据可识别密钥”(IKtkt)，将票据与LTC绑定为:H(LTCv ||ts ||te ||RndIKt kt)(步骤6.3-6.4);这可以防止恶意的LTCA在解析过程中映射不同的LTC。然后LTCA封装(步骤6.5)、签名(步骤6.6)并交付响应(步骤6.7)。