CN112152989A - 用于更新用于第三方电信提供方的应用层的方法和系统 - Google Patents

Abstract

本公开的实施例涉及用于更新用于第三方电信提供方的应用层的方法和系统。一种在包括防火墙和至少一个应用的系统处的方法，该方法包括在至少一个应用处针对至少一个应用获取用于服务提供方的新地址；触发防火墙更新；获取新的防火墙配置；以及更新防火墙，其中更新防火墙允许从至少一个应用到用于服务提供方的新地址的连接。

Description

用于更新用于第三方电信提供方的应用层的方法和系统

技术领域

本公开涉及到系统的数据提供，并且具体地涉及到系统的数据提供源的改变。

背景技术

系统内的应用可能需要外部数据才能操作。例如，在交通工具系统中，电子控制单元(ECU)可以包括需要从外部服务器获取更新、服务或其他数据的软件代码。

通常，这样的应用位于防火墙后面，以保护系统免受恶意行为者的侵害。在这点上，来自外部服务器的数据可能需要通过这样的防火墙才能被应用获取。在某些情况下，应用与外部服务器之间的连接可以由防火墙通过白名单来允许，也可以基于黑名单被拒绝。

然而，如果向系统内的应用提供数据的外部服务器发生改变，则防火墙和应用中的一者或两者也需要高效且安全地改变，以允许将来自新的外部服务器的数据提供给应用。

附图说明

参考附图将能够更好地理解本公开，在附图中：

图1是示出用于计算系统的示例架构的框图，该计算系统具有位于一个或两个防火墙后面的多个域控制器；

图2是示出用于计算系统的示例架构的框图，该计算系统具有用于检查去往和来自公共外部网络的通信的第一防火墙和用于检查去往和来自私有外部网络(OEM云)的通信的第二防火墙；

图3是示出从外部服务器获取用于防火墙的配置更新的数据流程图；

图4是示出用于电子控制单元的更新的加载的数据流程图；

图5是示出网关基于接收新的服务提供方地址的应用来监测和更新防火墙的数据流程图；

图6是示出应用接收用于服务提供方的新地址以及网关将与新的服务提供方建立连接的尝试解释为用以获取防火墙更新的触发的数据流程图；

图7是示出应用接收用于服务提供方的新地址并且向网关提供用以更新防火墙的信息的数据流程图；

图8是示出网关获取用于防火墙的包括服务提供方更新的配置信息并且从应用透明地中继通信或向应用提供新地址的数据流程图；

图9是示出当应用接收到用于服务提供方的新地址时应用提示网关检查新的防火墙更新的数据流程图；以及

图10是能够与本公开的实施例一起使用的简化的计算设备的框图。

具体实施方式

本公开提供了一种在包括防火墙和至少一个应用的系统处的方法，该方法包括：在至少一个应用处针对至少一个应用获取用于服务提供方的新地址；触发防火墙更新；获取新的防火墙配置；以及更新防火墙，其中更新防火墙允许从至少一个应用到用于服务提供方的新地址的连接。

本公开还提供了一种包括防火墙和至少一个应用的计算系统，该计算系统包括：处理器；以及通信子系统，其中计算系统被配置为：在至少一个应用处针对至少一个应用获取用于服务提供方的新地址；触发防火墙更新；获取新的防火墙配置；以及更新防火墙，其中更新防火墙允许从至少一个应用到用于服务提供方的新地址的连接。

本公开还提供了一种用于存储指令代码的计算机可读介质，该指令代码在由具有防火墙和至少一个应用的计算系统的处理器执行时使该计算系统：在至少一个应用处针对至少一个应用获取用于服务提供方的新地址；触发防火墙更新；获取新的防火墙配置；以及更新防火墙，其中更新防火墙允许从至少一个应用到用于服务提供方的新地址的连接。

在下面描述的实施例中，以下术语可以具有以下含义，如表1中提供的。

表1：术语

根据本公开的实施例，各种解决方案解决了如何高效且安全地仅改变托管或使应用感兴趣的内容可用的外部服务器标识符(诸如名称、域和/或地址)的问题。换言之，用于处理数据的应用代码保持不变，但是与服务器或云的通信端点发生改变。

在下面描述的示例中，应用是交通工具计算系统的一部分。然而，交通工具系统的使用仅被提供作为示例，并且在其他实施例中，其中应用位于防火墙后面的其他类型的计算系统同样适用于本文中描述的方法和系统。防火墙通常被实现为交通工具上的汽车网关的一部分或与之相结合来实现。

此外，尽管在本公开中经常陈述防火墙在网关中，但是在备选实施例中，防火墙可以在ECU或域控制器中。同样，在某些情况下，端点与服务器之间的任何通信路径中可以存在一个以上的防火墙，例如，在ECU、域控制器和网关上可以存在防火墙。此外，根据本文中描述的技术，在某些情况下，对这些多个防火墙进行更新是可能的。

此外，在本公开中，网关被描述为执行各种功能。然而，当本公开提供网关执行功能时，在某些情况下，这可以表示，被托管在网关上的防火墙或其他软件/功能执行该功能。

在交通工具环境中，可以安全地将软件更新从交通工具的原始设备制造方(OEM)下载到交通工具中的网关。然而，从远程源更新交通工具内的电子控制单元(ECU)是更困难的问题，因为在某些情况下，ECU可能不允许通过空中进行软件更新，或者在其他情况下，交通工具制造方可能认为这样的系统的远程更新风险太大。在其他情况下，不同的ECU制造方使用各种不同的专有软件更新方案，并且使用于互连ECU的网络和总线类型不同使得ECU软件更新问题是解决起来很复杂的问题。如果希望支持改变外部内容服务器的可能性，同时使消费该内容的应用保持不变，则优选地并且有可能在不涉及ECU端点的软件更新的外部内容服务器中寻求解决该变化问题的方法。

例如，ECU可以与交通工具内的信息娱乐系统相关联。信息娱乐系统可以包括导航应用，该导航应用使用外部服务器向ECU提供地图数据。如果这样的地图数据的位置或提供方发生改变，则交通工具上的应用和防火墙中的一者或两者需要了解该变化，并且允许数据来自新的外部服务器。

如下所述，在某些情况下，高级解决方案涉及网关利用新的通用资源定位符(URL)或与云服务和/或服务器相关联的其他地址来修改防火墙。在这种解决方案中，应用本身无法更新，但是网关可以获取新的防火墙配置以更新防火墙上的白名单，从而反映要用于该应用的外部服务器的变化。

在一些实施例中，网关可以采用应用代理并且读取由OEM云配置服务器提供给应用的新URL，并且从而更新防火墙。

备选地，可以触发网关以自行检查防火墙更新。例如，这可以是响应于应用访问不在防火墙处的白名单上的内容服务器的尝试。

在又一备选实施例中，网关可以打开到新服务器的安全隧道，该隧道对于应用是未知的，该应用具有的印象是它仍在与旧服务器通信。

下面进一步提供用于更新防火墙的其他实施例。

如本文中使用的，网关可以是包含或托管多个功能的ECU。通常，它是一种硬件和软件平台，其支持以下中的一项或多项：不同的内部和外部网络的互连、路由、桥接、协议转换、设立防火墙、中间人TLS检查、安全的交通工具内或交通工具外隧道、OTA软件更新功能(例如，请求、接收、存储和检查软件更新以分发给其他ECU)、收集日志以进行上载、以及其他功能。

现在参考图1，图1示出了用于与本文中描述的实施例一起使用的交通工具的示例架构。在图1的示例中，交通工具110可以连接到诸如OEM云服务或服务器170等专用网络。该连接可以用于某些服务以及用于诊断或配置数据传输。

此外，交通工具110还可以与外部网络180通信以获取交通工具110内的用户/驾驶员应用所需要的各种数据。例如，来自外部网络180的服务可以包括导航、停车辅助、天气报告等这样的数据。在其他情况下，外部网络可以提供对交通工具110内的各种系统组件的更新。数据类型的其他选项也是可能的。

在图1的实施例中，交通工具110包括非军事区(DMZ)120，该DMZ 120包括面向外部的防火墙122和网关124。在图1的示例中，具有网关128的另外的防火墙126可以用于分隔交通工具内的安全或其他关键系统。例如，驾驶员替换域控制器(DC)130、车身和舒适DC 140、交通工具内载动力学中的动力总成(powertrain)DC 145、以及其他这样的域控制器可以与网关128通信。这些域控制器被认为更加敏感，并且因此位于防火墙126后面。

在其他情况下，敏感性较低或信任度较低的域控制器可以直接与DMZ 120内的网关124通信。例如，交通工具内载体验DC 150可以与网关124通信，并且提供诸如导航、社交媒体访问、媒体播放器以及其他这样的服务等服务。

与外部世界的通信通常通过电信控制单元160来发生，该电信控制单元160然后可以通过诸如短距离或长距离通信系统等通信信道进行通信。例如，在某些情况下，通信系统可以是提供与OEM云服务器170和/或外部网络180的连接的Wi-Fi或蜂窝通信系统。

然而，图1的架构仅仅是一个示例。其他架构也是可能的。例如，现在参考图2。在图2的实施例中，与从交通工具210到外部网络280的连接相比，可以提供从交通工具210到OEM云服务器270的单独的连接。例如，这种单独的连接可以共享相同的蜂窝物理或媒体访问控制(MAC)地址，但是可以通过使用蜂窝接入点名称(APN)进行分离。其他分离选项也是可能的。

在图2的架构中，DMZ 220可以在外部网络与托管可信或非安全关键应用(诸如交通工具内载体验DC 250)的交通工具内载网络之间包括第一防火墙222。防火墙226可以用于访问OEM云服务器274，该OEM云服务器274托管可信和安全关键应用，诸如图2的示例中所示的驾驶员替换DC 230、车身和舒适DC 240和动力总成交通工具内载动力学DC 245。防火墙222和226的配置可以通过网关224来进行。

与图1的实施例一样，电信控制单元260可以允许对OEM云270或外部网络280的无线访问。

在图1和图2的实施例中，防火墙122、126、222和226可以基于白名单而不是黑名单。也就是说，防火墙仅允许与白名单中列出的URL、域或IP地址的传出连接。所有其他连接尝试将被阻止。

此外，通常也阻止所有传入连接。为了诊断目的，可以触发交通工具去往云以上载其数据日志并且获取最新的配置文件，其中该触发可以例如经由到蜂窝调制解调器的短消息服务(SMS)来实现。

图1和图2的实施例仅被提供作为可以包括需要来自外部服务器的数据的应用的系统的示例。因此，其他架构同样是可能的。

经由网络进行ECU更新

使用诸如以上在图1或图2中描述的系统架构，可能需要更新系统内的软件。例如，在ECU上运行的应用可能需要更新。这种更新类似于对于蜂窝电话应用或个人计算操作系统而言常见的“安全补丁”。可以基于安全性要求，基于出于业务原因而进行的改变，或者针对特征更新来触发更新。

现在参考图3，图3示出了用于更新交通工具中的ECU的示例高级消息流。在图3的示例中，具有防火墙配置或日志记录模块312的网关310可以用于与OEM网络(诸如OEM云服务器314)建立安全隧道。在其他示例中，系统内的不同实体可以建立到OEM云服务器314的连接。

通常，由于OEM控制网关防火墙白名单，因此OEM服务器需要知道从交通工具进行的与外部服务器的所有连接。然而，在某些情况下，网关防火墙白名单可能会发生变化，诸如例如，如果不再允许应用联系某个服务器。在其他情况下，可能需要对临时禁用的服务进行改变。在其他情况下，如果应用要连接到不同服务器，则可能需要改变白名单。

用例的一个示例将涉及交通工具内的地图或导航应用。通常，这样的地图或导航应用将去往地图提供方服务器，并且检索当前和本地地图以供该应用使用。在某些情况下，这样的导航或地图数据的提供方可能会改变。更新可以仅包括应用要联系的内容服务器的地址。

在这点上，OEM云服务器314可以向网关310提供触发320。例如，在某些情况下，触发可以是短消息服务消息。然而，OEM服务器与网关之间的其他触发也是可能的。

网关310一旦接收到触发320，就可以建立到OEM云服务器的安全隧道或连接。例如，这样的安全连接在框330处示出，并且在某些情况下，可以是到服务器的传输层安全性(TLS)隧道或到服务器的虚拟专用网(VPN)互联网协议安全性(IPSec)隧道。安全连接或隧道的其他示例也是可能的。

一旦框330的安全连接建立，就可以为防火墙下载配置更新，如消息340所示。

然而，上面的一个问题是如何高效且安全地仅改变托管或使应用感兴趣的内容有效的外部服务器名称/域/地址。也就是说，用于处理的应用代码可以保持不变，但是通信的端点需要改变。

此外，上面的第一子问题是如何管理改变并且意识到改变而无需对交通工具内载应用的空中或软件更新。并非每个OEM都将具有针对空中软件更新的解决方案。

上面的第二子问题是如何更新防火墙白名单以允许到新IP地址或URL的连接，同时阻止到先前IP地址或URL的连接。

现在参考图4，图4示出了软件更新的两个步骤。在图4的示例中，从网关到ECU的软件更新的第二步可能比第一步更不安全且更复杂。特别地，OEM软件更新服务器414需要通过网关412将软件更新推送到ECU 410。在这点上，OEM软件更新服务器414可以将如利用消息420所示的软件更新下载到网关412。如利用消息430所示，下载的更新然后可以被加载到ECU。

在图4的实施例处的问题在于，期望的效果是运行消息420和430两者(或从OEM到ECU 410的一个消息集)。然而，无法直接访问ECU 410以下载软件或配置。

下载更新

在本文中描述的实施例中，网关利用用于服务的新URL或服务器地址来修改防火墙，以将数据提供给在系统内运行的应用。在这种类型的解决方案中，应用本身无法更新，但是网关可以获取新的防火墙配置以更新网关处的白名单，从而反映要用于该应用的外部服务器的变化。

具体地说，如果服务提供方的服务器被更新，例如要使用新的地图提供方，则连接所寻求的服务器的完全合格域名(FQDN)或统一资源标识符(URI)不在网关的防火墙白名单上是可能的。如贯穿说明书中使用的，所获取的地址可以用于对新地址处的旧的服务提供方，也可以用于新的服务提供方。

基于此，使用两个步骤来解决更新服务提供方的问题。第一步涉及变为了解URL(地址)的改变并且获取新的URL。这可以通过应用或网关来进行。

第二步是对防火墙或网关进行改变，等同于改变防火墙。

每个在下面描述。

管理改变

可以通过若干方式来管理向应用提供数据的服务器的改变。

在第一方面，应用和网关两者都可以知道该改变。例如，在一种情况下，应用可以获得新的URL。这可以通过与某个OEM服务器的超文本传输协议(HTTP)连接来进行。此外，网关可以对传入分组执行应用层分组检查以发现已经改变的信息。因此，在这个方面，应用可以通过HTTP连接来接收连接改变消息，该连接改变消息可以由网关检查，并且因此两者都知道该改变。

在第二方面，应用可以首先发现改变。在这种情况下，应用可以经由诸如到某个OEM服务器的HTTP连接等方式来获得新的URL。在这种情况下，网关不会检查或拦截消息传输。因此，网关第一次知道可能发生了改变是在应用尝试连接到新服务器并且防火墙不允许这样做时。在某些情况下，应用可以请求网关更新其防火墙，并且然后网关可以去往OEM云以获取新的配置文件。

在第三方面，网关可以在应用之前发现进行了改变。例如，网关(防火墙)可以周期性地或根据需要去往OEM服务器并且发现存在用于特定服务的新的URL。在这种情况下，防火墙可以在应用实际寻求到URL的连接之前获得利用新的URL替换旧的URL的命令。

更新防火墙

一旦应用和网关中的一者或两者知道服务器的改变，就需要更新防火墙白名单。具体地，如果防火墙未更新，则ECU应用将无法获得该服务。这可以通过多种方式来解决。

在第一方面，网关可以拦截来自不考虑该改变的应用的请求，并且建立到与该应用所请求的服务器不同的服务器的安全连接。在这种情况下，网关可以透明地将数据传递到新服务器或从新服务器传递数据。如本领域技术人员将理解的，在某些情况下，来自新服务器的数据格式可能需要与来自旧服务器的数据格式相似，以确保应用可以处理这样的数据。

在第二方面，网关可以在应用寻求新服务之前或之后自行更新防火墙。例如，在某些情况下，应用可以请求防火墙更新。在其他情况下，网关可以例如通过与OEM服务器的周期性的连接来获取信息，并且发现防火墙已经改变。在某些情况下，如果未基于来自应用的请求而执行更新，则网关可以向应用通知URL已经改变。在这点上，然后可以打开网关防火墙所允许的新连接，并且数据在应用与新服务器之间正常流动。

在第三方面，网关可以简单地更新防火墙，而无需与应用的任何特殊交互。例如，如果网关在应用之前或与应用并行地发现改变，则可以执行这个操作。

管理防火墙的改变和更新的各个方面可以以多种方式配对。这些在下面描述。

网关作为应用代理

在本公开的第一实施例中，应用和网关都可以找到新的服务提供方。此外，在该第一实施例中，网关可以在不与应用进行任何特殊交互的情况下更新防火墙。

特别地，现在参考图5。在图5的实施例中，应用510可以通过网关512与OEM服务器514通信以找到服务提供方。例如，这可以经由TLS隧道520(例如，经由超文本传输协议安全(HTTPS))利用到配置服务器的HTTP GET消息来进行。然而，其他消息传输可以等同地用于与OEM服务器514通信。

响应于HTTP GET消息，OEM服务器514向应用510提供新的服务提供方516的地址，如消息530所示。例如，这样的地址可以是新的URL。

网关512可以监测应用510与OEM服务器514之间的消息，并且在这点上，网关512可以解析响应消息530，如框532处所示，以确定已经为应用的服务分配了新的完全合格域名或URL。为了做到这一点，网关不仅可以采用防火墙，而且可以采用中间人(MITM)或应用层代理，以便解密信息并且提取新的URL。

如果如在网关处确定的那样分配了新地址，则网关可以在框534处检查消息的完整性以确保消息是合法的。该检查还可以包括确定白名单是否包括新的服务提供方地址。特别地，网关需要具有一种映射，以示出白名单中的哪个条目是与应用的服务提供方相对应的条目。该映射可以例如通过配置来实现。

然后，如框536处所示，网关可以利用新的URL来更新防火墙白名单，并且从白名单中移除旧的URL。

此后，当应用510试图与新的服务提供方516连接时，例如如利用消息540所示，则允许通过防火墙到新的服务提供方的连接。

根据图5的实施例，网关可以监测业务并且自行发现改变，而应用无需知道防火墙需要更新或执行任何明确的动作以更新防火墙。

网关安全地更新防火墙

在本公开的另外的实施例中，应用可以用于获取服务提供方的新地址，但是网关不拦截或检查用于获取这种新地址的消息。然而，在该实施例中，网关仍然可以更新防火墙而无需与应用进行任何特殊交互。在某些情况下，例如可以通过与服务器通信来获取地址。在其他情况下，可以将新的服务提供方URL提供给应用随后读取的配置文件。

现在参考图6。在图6的实施例中，应用610可以经由通过网关612中的防火墙的通信从OEM服务器614获取新的服务提供方地址。

例如，可以通过TLS隧道通过诸如HTTP GET消息等消息来获取新地址，如利用连接620所示。然而，用于获取新地址的其他选项也是可能的。

响应于对服务提供方的地址的请求，可以在框630处提供新的服务提供方的地址。然而，在某些情况下，应用610可能不知道该地址用于新提供方或可能没有意识到或没有能力向防火墙提供更新。

在这点上，如利用消息632所示，应用610尝试建立与新的服务提供方616的连接。然而，由于新的服务提供方616尚未在防火墙处的白名单上，因此网关612阻止该连接尝试。

在图6的实施例中，网关不仅阻止连接尝试，还可以检查以查看URL或地址不在白名单上，但是由于它与作为系统上的合法应用的应用相关联，因此网关可以继而去往OEM云以检查是否已经存在对应用服务提供方的更新。

特别地，如图6所示，网关612发现URI或URL不在白名单上，如框634处所示，并且然后可以向OEM服务器614发送消息以检查防火墙更新，如消息640所示。

网关从提供防火墙更新的OEM服务器接收回消息642。

如框650处所示，网关612然后可以通过添加新的服务提供方616并且移除旧的服务提供方来更新其防火墙白名单。

应用610可能需要等待直到防火墙打开，并且然后再次尝试。这利用消息652示出。在这种情况下，由于防火墙白名单已经更新，因此将允许消息652处的连接。

因此，基于图6的实施例，应用不需要向网关提供任何消息传输以显式地请求防火墙更新。

备选地，在某些情况下，应用本身可以请求更新防火墙。现在参考图7。

在图7的实施例中，应用710通过网关712与OEM服务器714通信以获取服务提供方信息。例如，这可以通过使用HTTP GET消息的TLS连接720来进行。然而，获取地址的其他消息传输也是可能的。

然而，在其他情况下，应用710可以如上所述监测配置文件(未示出)。

响应于获取服务提供方地址的请求，OEM服务器714在消息730中提供新的服务提供方的地址。在图7的实施例中，网关712不监测该消息，并且因此不知道服务提供方改变。

在接收消息730或读取配置文件并且找到改变时，应用710意识到服务提供方已经存在改变。在图7的实施例中，应用710具有在其中编程的足够的智能以意识到需要防火墙更新。在这点上，应用710可以向网关712发送消息732以便更新防火墙。

在接收到消息732时，网关712可以验证请求，如框734所示。特别地，消息732也可以为防火墙提供旧的服务提供方的FQDN/URL地址(如果应用具有其)以及应用从OEM服务器714获取的新的FQDN/URL。在某些情况下，可以利用网关可以能够在框734处验证的数字签名来对FQDN/URL配置进行加密保护，以确保地址改变是合法的改变。

一旦在框734处验证了请求，网关712然后可以利用在消息732中提供的信息来更新防火墙白名单，如框740处所示。这可以涉及添加新的服务提供方的地址并且移除旧的服务提供方的地址。

一旦防火墙被更新，应用710就可以通过成功通过防火墙来与新服务提供方716建立连接750。

因此，基于图7的实施例，应用710包含用于向网关通知服务提供方改变以便发生防火墙更新的软件。

应用不知道服务提供方地址改变

在本公开的另外的实施例中，网关可以周期性地或根据需要去往OEM服务器并且发现存在与服务提供方相关联的新地址。如果地址已经改变，则在某些情况下，网关可以利用白名单上的新的URL或地址来替换旧的URL或地址。此外，在该实施例中，网关可以拦截来自应用的用以建立到旧服务器的TLS隧道的请求，或者可以向应用告知服务提供方的地址已经改变。

现在参考图8。在图8的实施例中，应用810与网关812通信。此外，网关812可以与OEM服务器814通信。

根据图8的实施例，网关812可以通过打开与OEM服务器814的连接820来周期性地更新防火墙的配置。这种连接可以用于配置、诊断和/或下载，并且可以是仅算作空中软件更新的动作。

备选地，OEM服务器812可以向网关812发送诸如SMS消息等消息(未示出)以触发网关打开连接820。

一旦打开连接，网关上的防火墙软件就可以检查防火墙更新，如消息822所示。

OEM服务器814可以将防火墙更新(如消息824所示)提供回网关812。网关812然后可以更新防火墙白名单，如框830处所示。

不知道服务提供方的地址改变的应用810试图与旧的服务提供方建立连接，如消息840处所示。例如，该连接可以是到旧的服务提供方服务器的HTTP/TCP连接或HTTPS/TCP连接，如在应用内配置的。在某些情况下，旧的服务提供方可以在云中。

在图8的实施例中，网关是应用感知的，这表示网关知道服务提供方的旧地址，并且确定不再使用服务提供方的地址，并且确定应当使用由OEM服务器814提供的替换地址。在一种情况下，应用不知道新地址，并且因此网关代理拦截用以连接到如该应用中配置的外部服务器的应用请求，并且将该业务重定向到新的服务提供方816(如消息842所示)，而不需要了解应用。在这点上，代理将实例化与新的外部服务器的连接，以代表应用执行动作并且传递未被修改的消息840(例如，HTTP GET)的内容作为消息842。实际上，这可以实例化为两个单独的TLS隧道，例如一个TLS隧道在应用810与网关812内的应用代理之间，另一TLS隧道在网关812内的应用代理与新的服务提供方816之间。

在这种情况下，在应用与外部提供方服务器之间发生HTTP数据传输而应用不知道服务器的改变。假定数据格式在旧的服务提供方与新的服务提供方之间是兼容的，或者应用810能够从新的服务提供方816接收以特定格式的数据。

在备选实施例中，代替建立连接842，网关812可以向应用810提供诸如URI等新地址，如消息850所示。在这种情况下，应用810可以信任网关812，并且因此将存储在应用处的服务提供方信息重新配置到在消息850中提供的新地址。

此后，应用810可以能够通过防火墙与新的服务提供方816建立连接852。

因此，图8的实施例允许网关在没有来自应用810的干预的情况下更新防火墙白名单，并且进一步允许网关拦截从应用到旧的服务提供方的通信，并且建立对应用透明的第二连接，或者向应用通知服务提供方的地址的改变。

应用要求网关更新其防火墙

在另外的实施例中，应用可以在不知道网关的情况下获取新的服务提供方的地址。此外，在该实施例中，网关此后可以在接收到更新其防火墙的请求时更新其防火墙。

现在参考图9，其中应用910通过网关912与服务器914通信。服务器914例如可以是OEM服务器或云服务。

在图9的实施例中，应用910可以打开与OEM服务器914的连接920以进行配置和/或诊断，并且可以下载用于服务提供方的新地址，如消息930处所示。

应用910注意到服务提供方的地址到服务提供方916的地址的改变，并且因此通过更新防火墙消息932来通知网关912。更新防火墙消息932使用信令或控制消息而不是用户数据。

在接收到消息932时，网关912可以启动与服务器(诸如服务器914)的连接以检查防火墙更新，如利用消息940所示。网关912然后可以从服务器914接收具有防火墙更新的消息，利用消息942示出。消息940和942可以通过安全连接来发送。

一旦接收到消息942，网关912就可以更新其防火墙白名单，如框950处所示。

此后，如果应用910尝试打开与新的服务提供方916的连接(诸如HTTPS/TCP连接)，如利用消息960所示，则连接将成功。

因此，图9的实施例允许应用向网关通知需要启动防火墙更新。

对于以上图5至图9的每个实施例，服务器提供用于新的服务提供方的新地址，该地址可以是FQDN/URL，并且这样的服务器通常将签名该消息以允许在网关处进行验证。

此外，在某些情况下，图5至图9的实施例中的步骤可以在系统(诸如交通工具)加电或启动时并且在任何用户交互触发应用的激活之前发生。

上述网关、交通工具、ECU、系统、服务器和网络元件可以是任何计算设备或网络节点。这样的计算设备或网络节点可以包括任何类型的电子设备，包括但不限于诸如智能电话或蜂窝电话等移动设备。示例还可以包括固定或移动用户设备，诸如物联网(IoT)设备、端点、家庭自动化设备、医院或家庭环境中的医疗设备、库存跟踪设备、环境监测设备、能源管理设备、基础结构管理设备、交通工具或用于交通工具的设备、固定电子设备等。交通工具包括机动交通工具(例如，汽车、小汽车、卡车、公共汽车、摩托车等)、航空器(例如，飞机、无人飞行器、无人飞机系统、无人机、直升机等)、航天器(例如，航天飞机、太空飞机、太空舱、空间站、卫星等)、船只(例如，船舶、轮船、气垫船、潜艇等)、有轨交通工具(例如，火车和电车等)、以及其他类型的交通工具，包括上述中的任何一项的组合，无论是当前存在的还是之后出现的。

关于图10示出了计算设备的一个简化图。图10的计算设备可以是如上所述的任何移动设备、便携式设备、网络节点、ITS站、服务器或其他节点。

在图10中，设备1010包括处理器1020和通信子系统1030，其中处理器1020和通信子系统1030协作以执行上述实施例的方法。在一些实施例中，通信子系统1020可以包括例如用于不同无线电技术的多个子系统。

处理器1020被配置为执行可编程逻辑，该可编程逻辑可以与数据一起被存储在设备1010上，并且在图10的示例中被示出为存储器1040。存储器1040可以是任何有形的非瞬态的计算机可读存储介质。计算机可读存储介质可以是有形的或瞬态/非瞬态介质，诸如光学(例如，CD、DVD等)、磁性(例如，磁带)、闪存驱动器、硬盘驱动器或本领域已知的其他存储器。

作为存储器1040的备选或补充，设备1010可以例如通过通信子系统1030从外部存储介质访问数据或可编程逻辑。

通信子系统1030允许设备1010与其他设备或网络元件通信，并且可以基于所执行的通信类型而变化。此外，通信子系统1030可以包括多种通信技术，包括任何有线或无线通信技术。

在一个实施例中，设备1010的各个元件之间的通信可以通过内部总线1060进行。然而，其他形式的通信也是可能的。

本文中描述的实施例是具有与本申请技术的要素相对应的要素的结构、系统或方法的示例。该书面描述可以使得本领域技术人员能够制造和使用具有与本申请的技术的要素同样相对应的备选要素的实施例。因此，本申请的技术的预期范围包括与本文所述的本申请的技术没有不同的其他结构、系统或方法，并且还包括与本文所述的本申请的技术具有实质性差异的其他结构、系统或方法。

尽管在附图中以特定顺序描绘了操作，但是这不应当被理解为要求以所示的特定顺序或以连续的顺序执行这样的操作，或者执行所有示出的操作以获取期望的结果。在某些情况下，可以采用多任务处理和并行处理。此外，在上述实现中的各种系统组件的分离不应当被理解为在所有实现中都需要这种分离，并且应当理解，所描述的程序组件和系统通常可以在单个软件产品中集成在一起或者打包成多种软件产品。

此外，可以将各种实现中描述和示出为离散或分离的技术、系统、子系统和方法与其他系统、模块、技术或方法组合或集成。被示出或讨论为彼此耦合或直接耦合或通信的其他项可以通过某种接口、设备或中间组件以电气、机械或其他方式间接耦合或通信。改变、替换和变更的其他示例可以由本领域技术人员确定并且可以被做出。

尽管上面的详细描述已经示出、描述并且指出了应用于各种实现的本公开的基本新颖特征，但是应当理解，可以由本领域技术人员对所示出的系统的形式和细节做出各种省略、备选以及变化。另外，方法步骤的顺序并不由它们出现在权利要求中的顺序所暗示。

当消息被发送到电子设备或从电子设备发送消息时，这样的操作可能不是立即的，或者不是直接来自服务器。它们可以从服务器或支持本文中描述的设备/方法/系统的其他计算系统基础结构同步或异步地传递。前述步骤可以全部或部分地包括去往/来自设备/基础结构的同步/异步通信。此外，来自电子设备的通信可以是到网络上的一个或多个端点的。这些端点可以由服务器、分布式计算系统、流处理器等提供服务。内容传递网络(CDN)也可以向电子设备提供通信。例如，除了典型的服务器响应之外，服务器还可以供应或指示用于内容传递网络(CDN)的数据，以等待电子设备在以后的时间(诸如电子设备的后续活动)下载。因此，数据可以作为系统的一部分或与系统分开直接从服务器或其他基础结构(诸如分布式基础结构或CDN)发送。

通常，存储介质可以包括以下各项的任何项或某种组合：半导体存储设备，诸如动态或静态随机存取存储器(DRAM或SRAM)、可擦可编程只读存储器(EPROM)、电可擦可编程只读存储器(EEPROM)和闪存；磁盘，诸如固定、软盘和可移动磁盘；另一磁性介质，包括磁带；光学介质，诸如光盘(CD)或数字视盘(DVD)；或其他类型的存储设备。注意到，以上讨论的指令可以在一个计算机可读或机器可读存储介质上提供，备选地可以在分布在具有可能多个节点的大型系统中的多个计算机可读或机器可读存储介质上提供。这样的(一个或多个)计算机可读或机器可读存储介质被认为是物品(或制品)的一部分。物品或制品可以是指任何制造的单个组件或多个组件。一个或多个存储介质可以位于运行机器可读指令的机器中，也可以位于可以通过网络下载机器可读指令以执行的远程站点处。

在前面的描述中，阐述了很多细节以提供对本文中公开的主题的理解。然而，可以在没有这些细节中的一些的情况下实践实现。其他实现可以包括对以上讨论的细节的修改和变化。旨在所附权利要求覆盖这些修改和变型。

Claims (19)

1.一种在系统处的方法，所述系统包括防火墙和至少一个应用，所述方法包括：

在所述至少一个应用处，针对所述至少一个应用获取用于服务提供方的新地址；

触发防火墙更新；

获取新的防火墙配置；以及

更新所述防火墙，

其中所述更新所述防火墙允许从所述至少一个应用到用于所述服务提供方的所述新地址的连接。

2.根据权利要求1所述的方法，其中所述触发基于从所述至少一个应用到用于所述服务提供方的所述新地址的连接尝试。

3.根据权利要求1所述的方法，其中所述触发基于从所述应用到所述防火墙的防火墙更新消息。

4.根据权利要求1所述的方法，其中所述获取所述新地址是通过配置服务器与所述应用之间的安全连接进行的。

5.根据权利要求1所述的方法，其中所述获取所述新的防火墙配置是通过所述防火墙与所述服务器之间的安全连接进行的。

6.根据权利要求1所述的方法，其中所述新地址是以下中的至少一项：统一资源定位符、统一资源标识符、互联网协议地址；以及完全合格域名。

7.根据权利要求1所述的方法，其中所述防火墙包含白名单。

8.根据权利要求1所述的方法，其中所述系统是交通工具，并且所述服务器是原始设备制造方服务器。

9.根据权利要求1所述的方法，其中所述更新所述防火墙包括：移除旧地址，并且添加用于所述服务提供方的所述新地址。

10.一种包括防火墙和至少一个应用的计算系统，所述计算系统包括：

处理器；以及

通信子系统，

其中所述计算系统被配置为：

在所述至少一个应用处，针对所述至少一个应用获取用于服务提供方的新地址；

触发防火墙更新；

获取新的防火墙配置；以及

更新所述防火墙，

其中所述更新所述防火墙允许从所述至少一个应用到用于所述服务提供方的所述新地址的连接。

11.根据权利要求10所述的计算系统，其中所述计算系统被配置为基于以下被触发：从所述至少一个应用到用于所述服务提供方的所述新地址的连接尝试。

12.根据权利要求10所述的计算系统，其中所述计算系统被配置为基于从所述应用到所述防火墙的防火墙更新消息被触发。

13.根据权利要求10所述的计算系统，其中所述计算系统被配置为通过配置服务器与所述应用之间的安全连接来获取所述新地址。

14.根据权利要求10所述的计算系统，其中所述计算系统被配置为通过所述防火墙与所述服务器之间的安全连接来获取所述新的防火墙配置。

15.根据权利要求10所述的计算系统，其中所述新地址是以下中的至少一项：统一资源定位符、统一资源标识符、互联网协议地址；以及完全合格域名。

16.根据权利要求10所述的计算系统，其中所述防火墙包含白名单。

17.根据权利要求10所述的计算系统，其中所述计算系统是交通工具计算系统，并且所述服务器是原始设备制造方服务器。

18.根据权利要求10所述的计算系统，其中所述计算系统被配置为通过移除旧地址，并且添加用于所述服务提供方的所述新地址来更新所述防火墙。

19.一种用于存储指令代码的计算机可读介质，所述指令代码在由具有防火墙和至少一个应用的计算系统的处理器执行时，使所述计算系统：

在所述至少一个应用处，针对所述至少一个应用获取用于服务提供方的新地址；

触发防火墙更新；

获取新的防火墙配置；以及

更新所述防火墙，

其中所述更新所述防火墙允许从所述至少一个应用到用于所述服务提供方的所述新地址的连接。

Images