CN110235424B - 用于在通信系统中提供和管理安全信息的设备和方法 - Google Patents

用于在通信系统中提供和管理安全信息的设备和方法 Download PDF

Info

Publication number
CN110235424B
CN110235424B CN201880007940.XA CN201880007940A CN110235424B CN 110235424 B CN110235424 B CN 110235424B CN 201880007940 A CN201880007940 A CN 201880007940A CN 110235424 B CN110235424 B CN 110235424B
Authority
CN
China
Prior art keywords
secondary device
information
service provider
key
mobile
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201880007940.XA
Other languages
English (en)
Other versions
CN110235424A (zh
Inventor
郑秀研
申仁暎
元银泰
李国熙
李钟孝
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020170119878A external-priority patent/KR20180086118A/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of CN110235424A publication Critical patent/CN110235424A/zh
Application granted granted Critical
Publication of CN110235424B publication Critical patent/CN110235424B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本公开涉及传感器网络、机器类型通信(MTC)、机器到机器(M2M)通信以及用于物联网(IoT)的技术。提供了一种用于在通信系统中提供和管理安全信息的设备和方法。一种第一装置的方法包括：检测第二装置请求共享第一装置的安全信息；在服务提供商处注册第二装置的信息；从服务提供商接收针对第二装置的用于共享第一装置的安全信息的认证信息；以及向第二装置发送所述认证信息。

Description

用于在通信系统中提供和管理安全信息的设备和方法
技术领域
本公开总体上涉及一种用于在通信系统中提供和管理安全信息的设备和方法。
背景技术
互联网作为人产生信息并消费信息的以人为中心的连接网络，现在正发展为分布式实体(即事物)在没有人为干预的情况下交换信息和处理信息的物联网(IoT)。作为IoT技术和大数据处理技术通过与云服务器的连接而成的结合体的万物互联(IoE)已经出现。
作为技术要素，诸如IoT实施、传感器网络、机器到机器(M2M)通信、机器类型通信(MTC)等所需的“传感技术”、“有线/无线通信和网络基础设施”、“服务接口技术”和“安全技术”最近已被研究。
这样的IoT环境可提供对在连接的事物之间产生的数据进行收集和分析的智能互联网技术服务。IoT可通过现有的信息技术(IT)和各种工业应用之间的融合和组合而被应用于各种领域，包括智能家居、智能建筑、智能城市、智能汽车或联网汽车、智能电网、医疗保健系统、智能家电和高级医疗服务。
汽车工业也已开发了各种类型的关键技术，并使用所开发的关键技术为驾驶员提供了便利。
例如，开发了一种使用机械钥匙打开车门并启动发动机的转动钥匙启动器技术，随后，开发了一种在不使用机械钥匙的情况下打开/关闭车门并启动发动机的远程无钥匙进入技术。远程无钥匙进入技术与防盗技术相结合，以便仅在根据防盗技术的使用，车辆钥匙的唯一密码与车辆的唯一密码相同时启动发动机。
最近，被动启动和进入(PASE)技术已被提出，并被应用于智能钥匙。与在驾驶员已从包中取出钥匙后需要驾驶员按下钥匙按钮的传统按钮型无线钥匙不同，即使驾驶员没有从包中取出智能钥匙，智能钥匙也可打开车门。此外，如果驾驶员按下车辆中的启动按钮而非转动钥匙，则发动机可启动。在智能钥匙技术中，如果在驾驶员座位附近没有授权钥匙，则发动机不启动并且方向盘不解锁，以防止车辆被盗。智能钥匙技术也已发展成各种形式。
已开发了一种被集成到移动终端(例如，使用无线通信技术(诸如近场通信(NFC)技术)的智能电话)中的钥匙。也就是说，数字化的虚拟钥匙(即，数字钥匙(DK))被包括在智能电话中，因此驾驶员不必携带钥匙。
如上所述，在汽车工业中，钥匙技术已经从简单的机械钥匙发展到遥控钥匙，从遥控钥匙发展到智能钥匙，并从智能钥匙发展到DK。因此，基于这些车辆和智能电话技术的组合，携带单独的车钥匙的需求可能消失。
此外，DK游戏的引入可扩展车辆共享服务。也就是说，在汽车工业中，概念随着自驾车时代正在从车辆占有变为车辆共享。
DK的使用在用户便利性和工业效果方面具有显著进步，然而，引起了许多安全问题。例如，因为DK可能与移动终端有关，所以DK会暴露于恶意使用，诸如黑客攻击等。因此，对提供和使用可信DK的方案存在需求。
此外，钥匙服务器提供DK(例如，服务提供商向拥有DK的所有者的装置(例如，车主的智能装置)提供DK)。如果除了所有者装置之外的另一装置(例如，客户端装置)想要共享所有者装置的DK，则客户端装置在钥匙服务器处注册账户，订阅DK服务，并请求钥匙服务器向客户端装置提供DK。
在这种情况下，钥匙服务器应单独管理客户端装置的账户。
此外，客户端装置执行DK获得过程，其中，DK获得过程包括多个处理，例如，在钥匙服务器处注册账户以共享所有者装置的DK，订阅DK服务，请求钥匙服务器提供DK，并从钥匙服务器接收DK。因此，还需要一种减少由钥匙服务器管理的账户的数量，并按照可信方案与客户端装置共享所有者装置的DK的方案。
发明内容
技术问题
因此，使本公开至少解决上述问题和/或缺点并至少提供下述优点。
本公开的一方面在于提供一种用于在通信系统中提供和管理安全信息的设备和方法。
本公开的另一方面在于提供一种用于在通信系统中共享安全信息的设备和方法。
本公开的另一方面在于提供一种用于在通信系统中增强对共享安全信息的装置的认证的设备和方法。
本公开的另一方面在于提供一种用于在通信系统中在没有在服务器注册账户的情况下获得安全信息的设备和方法。
本公开的另一方面在于提供一种用于在通信系统中增强安全信息的可靠性的设备和方法。
技术方案
根据本公开的一方面，提供了一种通信系统中的第一装置的方法。所述方法包括：检测第二装置请求共享第一装置的安全信息；在服务提供商处注册第二装置的信息；从服务提供商接收针对第二装置的用于共享第一装置的安全信息的认证信息；以及向第二装置发送所述认证信息。
根据本公开的另一方面，提供了一种通信系统中的第一装置的方法。所述方法包括：向服务提供商请求第二装置共享第一装置的安全信息的服务；从服务提供商接收针对第二装置的用于共享第一装置的安全信息的第一认证信息；基于第一认证信息和第一装置的安全信息，产生针对第二装置的用于共享第一装置的安全信息的第二认证信息；以及向第二装置发送第二认证信息。
根据本公开的另一方面，提供了一种通信系统中的第二装置的方法。所述方法包括：请求第一装置共享第一装置的安全信息；从第一装置接收针对第二装置的用于共享第一装置的安全信息的认证信息；基于所述认证信息与服务提供商执行认证操作；以及从服务提供商接收第一装置的安全信息。
根据本公开的另一方面，提供了一种通信系统中的第二装置的方法。所述方法包括：与第一装置建立连接；从第一装置接收针对第二装置的用于共享第一装置的认证信息的第一认证信息以及针对第二装置的用于共享第一装置的安全信息的第二认证信息，其中，所述第二认证信息是基于第一装置的安全信息产生的；请求服务提供商共享第一装置的安全信息；以及从服务提供商接收第一装置的安全信息。
根据本公开的另一方面，提供了一种通信系统中的服务提供商的方法。所述方法包括：从第一装置接收第二装置的信息；注册第二装置的信息；产生针对第二装置的用于共享第一装置的安全信息的认证信息；向第一装置发送所述认证信息；基于所述认证信息与第二装置执行认证操作；以及向第二装置发送第一装置的安全信息。
根据本公开的另一方面，提供了一种通信系统中的服务提供商的方法。所述方法包括：检测第二装置请求共享第一装置的安全信息的服务；产生针对第二装置的用于共享第一装置的安全信息的第一认证信息；向第一装置发送第一认证信息；检测第二装置请求共享第一装置的安全信息；以及向第二装置发送第一装置的安全信息。
根据本公开的另一方面，提供了一种在通信系统中使用的第一装置。第一装置包括：收发器；和处理器，其中，处理器被配置为：检测第二装置请求共享第一装置的安全信息；在服务提供商处注册第二装置的信息；经由收发器从服务提供商接收针对第二装置的用于共享第一装置的安全信息的认证信息；以及经由收发器向第二装置发送所述认证信息。
根据本公开的另一方面，提供了一种在通信系统中使用的第一装置。第一装置包括：收发器；和处理器，其中，处理器被配置为：向服务提供商请求第二装置共享第一装置的安全信息的服务；从服务提供商接收针对第二装置的用于共享第一装置的安全信息的第一认证信息；基于第一认证信息和第一装置的安全信息，产生针对第二装置的用于共享第一装置的安全信息的第二认证信息；以及经由收发器向第二装置发送第二认证信息。
根据本公开的另一方面，提供了一种在通信系统中使用的第二装置。第二装置包括：收发器；和处理器，其中，处理器被配置为：请求第一装置共享第一装置的安全信息；经由收发器从第一装置接收针对第二装置的用于共享第一装置的安全信息的认证信息；基于所述认证信息与服务提供商执行认证操作；以及经由收发器从服务提供商接收第一装置的安全信息。
根据本公开的另一方面，提供了一种在通信系统中使用的第二装置。第二装置包括：收发器；和处理器，其中，所述处理器被配置为：与第一装置建立连接；经由收发器从第一装置接收针对第二装置的用于共享第一装置的认证信息的第一认证信息以及针对第二装置的用于共享第一装置的安全信息的第二认证信息，其中，所述第二认证信息是基于第一装置的安全信息产生的；请求服务提供商共享第一装置的安全信息；以及经由收发器从服务提供商接收第一装置的安全信息。
根据本公开的另一方面，提供了一种在通信系统中使用的服务提供商。服务提供商包括：收发器；和处理器，其中，处理器被配置为：经由收发器从第一装置接收第二装置的信息；注册第二装置的信息；产生针对第二装置的用于共享第一装置的安全信息的认证信息；经由收发器向第一装置发送所述认证信息；基于所述认证信息与第二装置执行认证操作；以及经由收发器向第二装置发送第一装置的安全信息。
根据本公开的另一方面，提供了一种在通信系统中使用的服务提供商。服务提供商包括：收发器；和处理器，其中，处理器被配置为：检测第二装置请求共享第一装置的安全信息的服务；产生针对第二装置的用于共享第一装置的安全信息的第一认证信息；经由收发器向第一装置发送第一认证信息；检测第二装置请求共享第一装置的安全信息；以及经由收发器向第二装置发送第一装置的安全信息。
附图说明
从以下结合附图的描述，本公开的特定实施例的以上和其他方面、特征和优点将更加明显，其中：
图1示出根据本公开的实施例的通信系统的内部结构；
图2示出根据本公开的实施例的在通信系统中提供DK的处理；
图3示出根据本公开的实施例的在通信系统中提供DK的处理；
图4示出根据本公开的实施例的在通信系统中提供DK的处理；
图5是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图6A和图6B是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图7示出根据本公开的实施例的通信系统中的主装置的操作处理；
图8是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图9A和图9B是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图10A和图10B是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图11是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图12示出根据本公开的实施例的在通信系统中验证次级装置的位置的处理；
图13是示出根据本公开的实施例的通信系统中的主装置的操作处理的流程图；
图14是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图15示出根据本公开实施例的在通信系统中对次级装置进行验证的处理；
图16A和图16B是示出根据本公开的实施例的根据在通信系统中对次级装置进行验证的处理的信号发送/接收处理的信号流图；
图17是示出根据本公开的实施例的通信系统中的主装置和次级装置之间的连接处理的信号流图；
图18是示出根据本公开的实施例的在通信系统中注册次级装置的处理的信号流图；
图19是示出根据本公开的实施例的在通信系统中注册次级装置的处理的信号流图；
图20A和图20B是示出根据本公开的实施例的在通信系统中注册次级装置的处理的信号流图；
图21是示出根据本公开的实施例的在通信系统中注册次级装置的处理的信号流图；
图22是示出根据本公开的实施例的在通信系统中对次级装置进行认证的处理的信号流图；
图23是示出根据本公开的实施例的在通信系统中对次级装置进行认证的处理的信号流图；
图24是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图25A和图25B是示出根据本公开的实施例的在通信系统中获得次级装置的信息的处理的信号流图；
图26A和图26B是示出根据本公开的实施例的在通信系统中获得次级装置的信息的处理的信号流图；
图27示出根据本公开的实施例的在通信系统中提供DK的处理；
图28示出根据本公开的实施例的在通信系统中提供DK的处理；
图29A至图29C是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图；
图30A和图30B是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置验证处理的信号流图；
图31示出根据本公开的实施例的通信系统中的DK共享服务的协议栈；
图32是示出根据本公开的实施例的通信系统中的主装置的操作处理的信号流图；
图33A和图33B是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图；
图34A和图34B是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图；
图35示出根据本公开的实施例的在通信系统中提供DK的处理；
图36是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图37示出根据本公开的实施例的在通信系统中提供DK的处理；
图38是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图；
图39示出根据本公开的实施例的通信系统中的属性的格式；
图40示出根据本公开的实施例的通信系统中的通用属性配置文件(GATT)配置文件堆栈；
图41A至图41C是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图；
图42A和图42B是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置验证处理的信号流图；
图43示出根据本公开的实施例的在通信系统中注册次级装置的处理；
图44是示出根据本公开的实施例的通信系统中的主装置的操作处理的流程图；
图45示出根据本公开的实施例的在通信系统中验证用户应用的处理；
图46是示出根据本公开的实施例的在通信系统中验证用户应用的处理的信号流图；
图47是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图；
图48示出根据本公开的实施例的通信系统中的可信执行环境(TEE)；
图49是示出根据本公开的实施例的在通信系统中在TEE中产生用户信息的处理的信号流图；
图50是示出根据本公开的实施例的在通信系统中在主装置中使用TEE执行担保操作的处理的信号流图；以及
图51是示出根据本公开的实施例的在通信系统中使用存储在可信应用(TA)处的用于担保DK共享服务的密钥来执行签名操作的处理的信号流图。
具体实施方式
现在将参照附图详细描述本公开的各种实施例。在以下描述中，诸如详细配置和组件的具体细节仅被提供以帮助全面理解本公开的这些实施例。因此，本领域普通技术人员将认识到，在不脱离本公开的范围和精神的情况下，可以对本文描述的各种实施例进行各种改变和修改。此外，为了清楚和简明，可以省略对公知功能和构造的描述。
在以下描述和权利要求中使用的术语和词语仅由发明人使用以提供对本公开的清楚和一致的理解。因此，提供本公开的各种实施例的以下描述仅用于说明目的，而不是为了限制由所附权利要求及其等同物限定的本公开的目的。
只要本文使用的术语(包括技术术语和科学术语)没有被不同地定义，这些术语就具有与本领域技术人员通常理解的术语相同的含义。此外，在通用字典中定义的术语具有与相关技术中的术语的含义一致的含义。
除非上下文另有明确指示，否则单数形式包括复数指示物。因此，例如，对“组件表面”的引用包括对一个或更多个这样的表面的引用。
尽管可使用诸如“第一”、“第二”等的序数来描述各种组件，但是这些术语仅用于将一个组件与另一组件区分开。例如，在不脱离本发明构思的教导的情况下，第一组件可被称为第二组件，并且同样地，第二组件也可被称为第一组件。
这里，这里使用的术语“和/或”包括一个或更多个相关所列项的任意组合和所有组合。
诸如“包括”、“包含”和“具有”的术语指示陈述的特征、数字、步骤、操作、组件、元素或它们的组合的存在，但不排除存在或添加一个或更多个其他特征、数字、步骤、操作、组件、元素或它们的组合。
这里，“所有者”可表示目标装置(例如，车辆)的所有者以及安全信息(例如DK，例如车辆钥匙)的原始所有者。所有者的装置(下文称为“所有者装置”)可以是主装置。
主装置表示已经由提供和管理安全信息的服务提供商(例如，服务器或OEM)认证的装置，并且由于主装置已经由服务提供商认证，因此主装置已经获得了目标装置的安全信息。例如，所有者装置已经获得了车辆的DK。
主装置、所有者装置或所有者终端表示可在安全信息被共享时存储安全信息的装置。例如，主装置可以是智能装置。
次级装置、用户装置或用户终端表示被提供安全信息的装置。例如，次级装置可以是智能装置。
DK共享客户端(SC)表示可发起命令、向DK共享服务器(DKSS)请求命令以及接收由DKSS发送的响应、指令和通知的实体。
DKSS表示可接受命令、向DKSC请求命令以及向DKSC发送响应、指令和通知的实体。
这里，电子装置可以是智能电话、平板个人计算机(PC)、移动电话、视频电话、电子书阅读器、台式PC，膝上型PC、上网本PC、个人数字助理(PDA)、便携式多媒体播放器(PMP)、mp3播放器、移动医疗装置、相机、可穿戴装置(例如，头戴式装置(HMD)、电子服装、电子支架、电子项链、电子配件、电子纹身或智能手表)等。
电子装置也可以是智能家用电器，诸如电视(TV)、数字视频盘(DVD)播放器、音频播放器、冰箱、空调、真空吸尘器、烤箱、微波炉、洗衣机、烘干机、空气净化器、机顶盒、电视盒(例如，Samsung HomeSyncTM、Apple TVTM或Google TVTM)、游戏机、电子词典、电子钥匙、摄像机、电子相框等。
电子装置也可以是医疗装置(例如，磁共振血管造影(MRA)装置、磁共振成像(MRI)装置、计算机断层扫描(CT)装置、成像装置或超声装置)、导航装置、全球定位系统(GPS)接收器、事件数据记录器(EDR)、飞行数据记录器(FDR)、车辆信息娱乐装置、海军电子装置(例如，海军导航装置、陀螺仪或罗盘)、航空电子装置、安全装置、工业或消费者机器人等。
电子装置也可以是家具、建筑物/结构的一部分、电子板、电子签名接收装置、投影仪、各种测量装置(例如，水、电、气或电磁波测量装置)等。
此外，电子装置可以是前述装置的任意组合。然而，根据本公开的各种实施例的电子装置不限于前述装置。
在本公开的实施例中提出的设备和方法可应用于各种通信系统，诸如在第三代合作伙伴计划2(3GPP2)中提出的长期演进(LTE)移动通信系统、LTE高级(LTE-A)移动通信系统、授权辅助接入(LAA)-LTE移动通信系统、高速下行分组接入(HSDPA)移动通信系统、高速上行分组接入(HSUPA)移动通信系统、高速分组数据(HRPD)移动通信系统、在3GPP2中提出的宽带码分多址(WCDMA)移动通信系统、在3GPP2中提出的码分多址(CDMA)移动通信系统、电气和电子工程师协会(IEEE)802.16m通信系统、IEEE802.16e通信系统、演进分组系统(EPS)、以及移动互联网协议(移动IP)系统、数字视频广播系统(诸如移动广播服务，诸如数字多媒体广播(DMB)服务、手持数字视频广播(DVP-H)、先进电视系统委员会-移动/手持(ATSC-M/H)服务等)和互联网协议电视(IPTV)系统、运动图像专家组(MPEG)媒体传输(MMT)系统等。
这里，安全信息包括例如DK和与DK有关的信息(例如，访问属性信息)。
用于发送和/或接收安全信息的设备可以是智能装置、车辆或钥匙服务器。
用于发送和/或接收安全信息的设备可以是应用了安全信息的目标装置，例如，为使用车辆而已被认证的主装置。主装置表示已由提供和管理安全信息的服务器认证的装置。因为主装置已经由服务器认证，所以主装置已经获得了用于目标装置的安全信息。可从提供和管理安全信息的服务器获得安全信息。
此外，因为主装置已经在服务器处被注册，所以关于主装置的信息已经在服务器处被注册。
用于发送和/或接收安全信息的装置可以是次级装置，即，尚未由服务器认证的装置。次级装置可通过主装置在服务器处被注册和认证，然后与主装置共享安全信息。
主装置和次级装置可以是智能装置，例如，移动站(MS)。
这里，术语MS可以与诸如用户设备(UE)、终端、装置、无线装置、移动装置、移动电话等的术语互换使用。
图1示出根据本公开的实施例的通信系统的内部结构。
参照图1，通信系统包括服务提供商100、可信服务管理器(TSM)110、智能装置120、安全元件(SE)发放器160和目标装置170。
TSM 110管理安全信息，例如，DK和与DK有关的信息。TSM 110使服务提供商100能够通过允许访问智能装置来远程分发和管理服务提供商100的非接触式应用。这里，术语服务提供商可以与术语“服务器”或“OEM”互换使用。
服务提供商100可管理安全信息并通过允许访问智能装置(例如，包括在智能装置中的安全元件)来远程分发和管理非接触式应用。
智能装置120包括操作系统130、嵌入式安全元件(eSE)140和通信模块150。这里，术语通信模块可与术语收发器等互换使用。
操作系统130包括移动用户接口(UI)131，其中，移动用户接口(UI)131是服务器100(或TSM 110)与智能装置120之间的接口。
eSE 140包括小应用程序141和控制器143(例如，“OPEN”)。eSE 140是包括在智能装置120中的安全存储装置。可选地，智能装置120可包括通用集成电路卡(UICC)SE而不是eSE 140。
小应用程序141是在eSE 140内运行的小型应用，并且可由TSM 110或SE发放器160加载或安装。控制器143控制与安全信息有关的整体操作。
除了eSE 140之外的各种元件可以是安全存储装置。也就是说，除了eSE 140之外或作为eSE 140的替代，智能装置120可包括单独的安全存储装置，使得安全信息可存储在该单独的安全存储装置中。
通信模块150可以是用于在目标装置170(例如，车辆)与智能装置120之间发送和/或接收信号的短程通信装置。例如，通信模块150可使用NFC方案在目标装置170和智能装置120之间发送和/或接收(收发)信号。可选地，通信模块150可使用不同的短程通信方案，诸如蓝牙、Wi-Fi、红外线通信、磁安全传输(MST)和磁安全通信。
目标装置170包括通信模块171，其中，通信模块171可以是用于在智能装置120和目标装置170之间例如使用NFC方案或其他短程通信方案收发信号的短程通信装置。
尽管图1中所示的每个实体包括多个模块，但是包括在每个实体中的模块可用至少一个处理器来实现。
图2示出根据本公开的实施例的在通信系统中提供DK的处理。
参照图2中，将注意，服务提供商被示出为“OEM服务器”，主装置被示出为“所有者终端”，并且次级装置被示出为“客户端终端”。此外，将注意，图2以术语“OEM服务器”、“所有者终端”和“客户端终端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
参照图2，通信系统包括服务提供商、主装置和次级装置。将假设次级装置未在服务提供商处被注册，因此在服务提供商中不存在次级装置的账户。
如果次级装置意图共享主装置的DK，则次级装置向主装置发送用于请求使用(共享)DK的消息。这里，请求共享DK的消息将被称为“钥匙共享请求消息”。钥匙共享请求消息包括次级装置的标识符(ID)和担保(1、客户端ID+客户端凭证)。
在从次级装置接收到钥匙共享请求消息时，主装置基于包括在钥匙共享请求消息中的次级装置的ID和担保来执行针对次级装置的验证操作。如果针对次级装置的验证结果成功，则主装置产生针对次级装置的担保(2、验证客户端+产生担保)。
如果针对次级装置的验证结果成功，则主装置向服务提供商发送用于请求注册次级装置的消息。这里，用于请求注册次级装置的消息将被称为“次级装置注册请求消息”。次级装置注册请求消息包括针对次级装置230的担保，并且该担保包括一次性密码(OTP)和访问属性(3、代替注册客户端(提交担保)和(可选的)访问属性)。
在从主装置接收到次级装置注册请求消息时，服务提供商执行针对包括在次级装置注册请求消息中的担保的确认操作(4、确认所有者担保)。如果确认结果成功，则服务提供商向主装置220发送对次级装置注册请求消息的响应消息(5、为客户端提供OTP)。这里，对次级装置注册请求消息的响应消息将被称为“次级装置注册响应消息”。次级装置注册响应消息包括服务提供商针对次级装置提供的OTP。
在从服务提供商接收到次级装置注册响应消息时，主装置向次级装置发送作为对次级装置注册请求消息的响应消息的次级装置注册结果通知消息(6、传送OTP)。这里，次级装置注册结果通知消息包括从服务提供商接收的针对次级装置的OTP。
在从主装置接收到次级装置注册结果通知消息时，次级装置基于包括在次级装置注册结果通知消息中的OTP与服务提供商执行认证操作(7、使用OTP认证客户端)。
如果针对次级装置的认证结果成功，则服务提供商向次级装置提供数字钥匙(8、提供数字钥匙)。
作为结果，图2中提供DK的处理将总结如下。
(1)首先，OEM服务器与客户端终端无关，
(2)所有者终端担保客户端终端，并代替客户端终端在OEM服务器注册客户端终端的客户端信息，
(3)所有者终端向客户端终端发送由OEM服务器提供的秘密信息(例如，OTP)，并且
(4)当客户端终端基于秘密信息请求服务时，OEM服务器提供DK。
图3示出根据本公开的实施例的在通信系统中提供DK的处理。
参照图3中，将注意，服务提供商被示出为“OEM服务器”，主装置被示出为“所有者终端”，并且次级装置被示出为“客户端终端”。此外，将注意，图3以术语“OEM服务器”、“所有者终端”和“客户端终端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图3中的数字钥匙提供处理是在主装置首先请求与次级装置进行钥匙共享并且服务提供商验证主装置提供的共享令牌的情况下的数字钥匙提供处理。
参照图3，如果主装置向服务提供商请求钥匙共享(1、钥匙共享请求)，则服务提供商提供随机数(nonce)(2、提供随机数)。这里，用于请求钥匙共享的钥匙共享请求消息可包括例如访问属性。
服务提供商向主装置发送提供的随机数(3、传送随机数)，并且主装置基于随机数和DK产生共享令牌(4、基于随机数和数字钥匙(或已经在主装置和服务提供商之间共享的共享秘密(SHS))产生共享令牌)。这里，随机数用于防止共享令牌的重复使用。
主装置与次级装置建立NFC连接(5、NFC连接)，并向次级装置发送共享令牌(6、传送共享令牌)。在从主装置接收到共享令牌时，次级装置向服务提供商请求服务，也就是说，次级装置请求DK提供(7、请求服务(例如，数字钥匙提供))，以便在次级装置和服务提供商之间执行针对共享令牌的验证操作(8、验证共享令牌)。
如果针对共享令牌的验证结果成功，则服务提供商向次级装置提供服务(9、提供服务)。也就是说，如果针对共享令牌的验证结果成功，则服务提供商向次级装置提供DK。
图4示出根据本公开的实施例的在通信系统中提供DK的处理。
参照图4，将注意，服务提供商被示出为“服务提供商”，主装置被示出为“所有者终端”，并且次级装置被示出为“客户端终端”。此外，将注意，图4以术语“服务提供商”、“所有者终端”和“客户端终端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图4中的数字钥匙提供处理是数字DK提供处理，其中，次级装置访问服务提供商，向服务提供商请求服务，并从服务提供商获得服务访问信息，并且主装置基于由次级装置获得的服务访问信息访问服务提供商，并执行用于认证的确认操作以及主要信息传送。
次级装置向服务提供商请求服务(1、请求服务)，因此服务访问信息在服务提供商和次级装置之间被传输(2、传送服务访问信息(网络(N/W)信息、统一资源定位符(URL)、服务ID等))。这里，服务访问信息可包括例如网络(N/W)信息、统一资源定位符(URL)信息、服务ID等。
次级装置向主装置发送服务访问信息和次级装置的信息(3、服务访问信息重传+客户端信息)。在从次级装置接收到服务访问信息和次级装置的信息时，主装置访问服务提供商(4、访问服务器)，并且所有者认证过程(即，主装置认证过程)在服务提供商和主装置之间被执行(5、认证所有者)。
如果主装置认证过程成功，则主装置向服务提供商请求服务(请求服务(钥匙提供、主要信息代替传送等)，并且(可选地)，访问属性被包括)。这里，服务请求可以是例如请求为次级装置提供DK的服务请求。
在从主装置接收到服务请求时，服务提供商向次级装置提供服务(7、提供服务(提供钥匙或传送从所有者接收的信息)。这里，从服务提供商向次级装置提供服务的操作可包括：将DK从服务提供商提供给次级装置，或者将从主装置接收的信息从服务提供商发送到次级装置。
图5是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图5，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图5以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图5中提供数字钥匙的处理是基于主装置共享数字钥匙的处理。
将注意，图5中提供数字钥匙的处理是根据如图2所述的数字钥匙提供处理的在服务提供商511、主装置513和次级装置515之间的信号发送/接收操作。
参照图5，在服务提供商511和主装置513之间共享诸如DK、主装置513的公共密钥(PK)、专用密钥等的各种钥匙(517)。此外，在主装置513和次级装置515之间产生安全连接(519)。
次级装置515向主装置513发送次级装置信息(例如，客户端信息)(521)。这里，次级装置信息可包括PK，例如，凭证以及关于次级装置ID的信息(例如，应用ID、电话号码、国际移动设备识别码(IMEI)、eSID、GPS信息等)。
在从次级装置515接收到次级装置信息时，主装置513基于次级装置信息执行针对次级装置515的验证操作(523)，并且如果验证操作的结果成功，则主装置513对已经在主装置513和服务提供商511之间共享的信息进行担保(525)。这里，担保操作可包括签名操作、加密操作等。
主装置513向服务提供商511发送担保的次级装置信息(527)。这里，担保的次级装置信息可以可选地包括访问属性等。
在从主装置513接收到担保的次级装置信息时，服务提供商511确认主装置513的担保信息和权限(529)，并注册次级装置515(531)。服务提供商511产生OTP，并使用次级装置515的PK来对OTP进行加密(533)。服务提供商511向主装置513发送经过加密的OTP(535)。主装置513向次级装置515发送从服务提供商511接收的经过加密的OTP(537)。在从主装置513接收到经过加密的OTP时，使用秘密密钥(SK)对经过加密的OTP进行解码以获取由服务提供商511产生的OTP(539)。
次级装置515向服务提供商511发送用于请求提供DK的钥匙提供请求(541)。这里，钥匙提供请求包括次级装置ID，即，次级装置515的客户端ID。
在从次级装置515接收到钥匙提供请求时，服务提供商511向次级装置515发送认证请求(543)。这里，认证请求可包括用于认证次级装置515的质询(challenge)。
在从服务提供商511接收到认证请求时，次级装置515基于包括在认证请求中的质询和获取的OTP来产生用于认证次级装置515的质询响应(质询rsp)(质询rsp＝质询+OTP)(545)。
次级装置515向服务提供商511发送包括质询rsp的认证响应(547)。
在接收到质询rsp时，服务提供商511提供针对次级装置515的DK，并向次级装置515发送提供的DK(549)。
如图5所述，所述处理包括：用于在主装置513和次级装置515之间建立连接的主装置-次级装置连接阶段(517和519)，用于注册次级装置515的信息的次级装置信息注册阶段(521至535)，和在次级装置515与服务提供商511之间执行认证过程的次级装置-服务提供商认证阶段(537至545)，以及用于向次级装置515提供DK的DK提供阶段(547和549)。
尽管图5的每个步骤都被示出为一系列操作的一部分，但是图5中的各个步骤可以重叠、并行发生、以不同顺序发生或多次发生。
图6A和图6B是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图6A和6B，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图6A和图6B以术语“OEM”、“所有者智能装置”和“客户端智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图6A和图6B中提供数字钥匙的处理是基于主装置共享数字钥匙的处理。
将注意，图6A和图6B中提供数字钥匙的处理是根据如图2所述的数字钥匙提供处理的在服务提供商、主装置和次级装置之间的信号发送/接收操作。
主装置603包括应用604和安全元件605，并且次级装置601包括应用602。
主装置603的应用604检测用户输入，即，共享钥匙属性设置(611)。这里，共享钥匙属性设置可包括例如访问级别、验证信息等。
主装置603的应用604检测用户输入，即，钥匙共享启动请求(613)。次级装置601的应用602检测用户输入，即，钥匙接收启动请求(615)。因此，在主装置603和次级装置601之间建立NFC对等(P2P)连接(617)。
主装置603的应用604向次级装置601的应用602发送请求次级装置601的信息的次级装置信息请求(619)。
在从主装置603的应用604接收到次级装置信息请求时，次级装置601的应用602向主装置603的应用604发送包括次级装置601的信息(即，次级装置信息)的响应。这里，次级装置信息可包括次级装置601的SE ID以及PK或凭证。
在从次级装置601的应用602接收到所述响应时，主装置603的应用604对包括在所述响应中的次级装置信息执行用户确认操作(用户确认)(625)。这里，用户确认操作可包括用户认证操作。
通过开放移动应用程序编程接口(API)(OMAPI)在主装置603的应用604和主装置603的安全元件605之间建立信道(627)。主装置603的应用604向主装置603的安全元件605发送用于命令执行安全操作的应用协议数据单元(APDU)命令(例如，执行安全操作APDU(PerformSecurityOperationAPDU)命令)(629)。这里，执行安全操作APDU命令可以是用于请求计算数字签名(DS)的APDU命令。
在从主装置603的应用604接收到执行安全操作APDU命令时，主装置603的安全元件605计算DS(631)。例如，主装置603的安全元件605基于输入数据和DK计算DS，并且输入数据可以是次级装置信息和DK ID。
主装置603的安全元件605向主装置603的应用604发送包括计算出的DS的响应(633)。
在从主装置603的安全元件605接收到包括DS的响应时，主装置603的应用604向服务提供商607发送次级装置注册请求(635)。这里，次级装置注册请求可包括次级装置信息、DS和DK ID，并且可以可选地包括钥匙属性。
在从主装置603的应用604接收到次级装置注册请求时，服务提供商607验证DS(637)。这里，服务提供商607从次级装置信息检测次级装置601的PK(例如，如图6B所示的“Client.pk”)，并通过基于主装置603的SHS和次级装置601的PK执行加密操作来计算次级装置601的OTP(例如，如图6B所示的ClientOTP)。
服务提供商607向主装置603的应用604发送对次级装置注册请求的响应(639)。对次级装置注册请求的响应可包括次级装置601的OTP和服务ID，并且可以可选地包括服务器信息(即，服务提供商607的信息)。
在从服务提供商607接收到对次级装置注册请求的响应时，主装置603的应用604向次级装置601的应用602发送次级装置注册结果通知(641)。次级装置注册结果通知可包括次级装置601的OTP和服务ID，并且可以可选地包括服务器信息。
在从主装置603的应用604接收到次级装置注册结果通知时，次级装置601的应用602通过基于次级装置601的PK对次级装置601的OTP进行解码来获得主装置603的SHS(643)。次级装置601的应用602向服务提供商607发送次级装置服务请求(645)。次级装置服务请求包括将要请求的服务的服务ID。
在从次级装置601的应用602接收到次级装置服务请求时，服务提供商607向次级装置601的应用602发送包括验证请求的响应。该响应还可包括质询。
在从服务提供商607接收到次级装置服务响应时，次级装置601的应用602计算质询响应(649)。例如，次级装置601的应用602基于质询和SHS计算质询响应。
次级装置601的应用602向服务提供商607发送次级装置验证请求(651)。次级装置验证请求包括质询响应。
在从次级装置601的应用602接收到次级装置验证请求时，服务提供商607对质询响应进行验证(653)。也就是说，服务提供商607基于质询和SHS计算质询响应，并基于计算出的质询响应与包括在次级装置验证请求中的质询响应是否相同来对质询响应进行验证。
服务提供商607向次级装置601的应用602发送包括验证结果的次级装置验证结果(655)。
尽管图6A和图6B将提供DK的处理示出为一系列操作，但是图6A和图6B中的各种操作可重叠、并行发生、以不同的顺序发生或多次发生。
图7示出根据本公开的实施例的通信系统中的主装置的操作处理。
参照图7，将注意，服务提供商被示出为“OEM服务器”，主装置被示出为“所有者电话”，并且次级装置被示出为“客户端”。此外，将注意，图7以术语“OEM服务器”、“所有者电话”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。将注意，图7中的主装置的操作处理是在基于主装置共享数字钥匙的情况下的主装置的操作处理。
将注意，图7中的主装置的操作处理是根据如图2所述的数字钥匙提供处理的主装置的操作处理。
主装置711的应用713从次级装置获得次级装置信息(721)。
主装置711的应用713对次级装置信息进行验证(723)，并向主装置711的补充安全域(SSD)717的小应用程序发送签名请求(725)。签名请求可包括次级装置信息。
主装置711的小应用程序基于DK产生代替注册形式(727)。可选地，小应用程序可基于安装在主装置711的小应用程序上的单独密钥而非DK来产生代替注册形式。所述单独密钥用于签名，并且可以在用于主装置711的DK被提供时被安装。
主装置711的小应用程序向主装置711的应用713发送所产生的代替注册形式(729)。
主装置711的应用713向服务提供商719发送从主装置711的小应用程序接收的代替注册形式(731)。主装置711的应用713可向服务提供商719发送访问属性和代替注册形式。
在接收到从主装置711的应用713接收的代替注册形式时，服务提供商719基于代替注册形式来验证主装置711(733)。如果针对主装置711的验证结果成功，则服务提供商719存储代替注册形式(735)，并产生针对次级装置的OTP(737)。服务提供商719向主装置711的应用713发送产生的OTP(739)。在从服务提供商719接收到OTP时，主装置711的应用713向次级装置发送接收到的OTP(741)。
图8是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图8，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图8以术语“OEM”、“所有者智能装置”和“客户端智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。主装置803的应用804向服务提供商807发送用于请求钥匙共享服务的消息(811)(1、钥匙共享请求(所有者ID)、(可选的)访问属性)。用于请求钥匙共享服务的消息可包括诸如主装置的标识符(例如，所有者ID)的ID等。用于请求钥匙共享服务的消息可以可选地包括诸如访问属性等的信息。访问属性可包括钥匙寿命、自动驾驶距离、与可以驾驶车辆的区域相关的信息(例如，地理围栏(例如，指示可以在特定区域驾驶车辆的信息))、车辆属性(例如，最大速度)以及车辆使用权限(例如，车门打开、后备箱打开、启动车辆)、车辆已被使用的次数(例如，车门被打开的次数、后备箱被打开的次数)等。
服务提供商807向主装置803的应用804发送对钥匙共享请求的响应、随机数和服务ID(813)(2、钥匙共享响应(随机数、服务ID))。随机数可用于防止在主装置803中产生令牌的重复使用。
当次级装置801请求钥匙提供(即，“7”操作)时，服务ID可用于在服务提供商807、主装置803和次级装置801之间匹配服务同步。服务提供商807计算共享令牌，并且共享令牌是基于输入数据和共享的DK(DK.sharing)计算出的(例如，OEM计算Shr.Token＝Hash(输入数据，DK.sharing))。
主装置803的应用804向主装置803的安全元件805发送用于命令执行安全操作的执行安全操作APDU命令。安全操作可以是令牌产生操作。
在从主装置803的应用804接收到执行安全操作APDU命令时，主装置803的安全元件805使用存储在主装置803的安全元件805处的DK或具有与DK等同权限的钥匙来产生共享令牌(819)。例如，可基于DK或具有与DK等同权限的钥匙并且基于从服务提供商807提供的随机数来产生共享令牌。
主装置803的安全元件805向主装置803的应用804发送包括产生的共享令牌的响应(821)。(3、执行安全操作APDU：令牌产生操作；4、Shr.Token＝Hash(输入数据，DK.sharing)；5、rsp.(Shr.Token))。
然后，在次级装置801和主装置803之间建立基于短程通信方案(诸如NFC、蓝牙(BT)等)的通信环境。在图8中，将假设在次级装置801和主装置803之间建立基于NFC方案的通信环境。也就是说，在图8中，将假设在次级装置801和主装置803之间建立NFC连接(NFC连接建立)。因此，将假设在次级装置801和主装置803之间产生安全信道。
主装置803向次级装置801的应用传送共享令牌和服务ID(825)(6、传送ShrToken和服务ID)。
次级装置801向服务提供商807请求DK共享(827)(7、钥匙共享请求(服务ID))。DK共享请求可包括服务ID，其中，服务提供商807可从服务ID识别出次级装置801已连接到哪个主装置。
服务提供商807向次级装置801发送请求对共享令牌进行验证的共享令牌验证请求(829)(8、ShrToken验证请求(质询))。这里，共享令牌验证请求可包括质询。
服务提供商807请求对共享令牌进行验证以检查次级装置801是否具有由主装置803产生的共享令牌。
在从服务提供商807接收到共享令牌验证请求时，次级装置801计算质询响应(831)，并向服务提供商807发送计算出的质询响应(833)(9、计算质询响应＝f(ShrToken，质询)；10、质询响应)。可基于(由主装置803提供的)共享令牌和(由服务提供商807提供的)质询来产生质询响应。
服务提供商807基于值计算共享令牌(随机数+DK)，并计算质询响应(共享令牌+质询)(835)(11、OEM计算质询响应＝f(ShrToken_by OEM，质询))。服务提供商807对从次级装置801接收的质询响应进行验证(837)(12、由OEM通过与质询响应进行比较来对质询响应进行验证)。
服务提供商807知道随机数的值和质询的值，并可通过所有者ID知道主装置803使用的DK。
因此，服务提供商807基于所述值计算共享令牌(随机数+数字钥匙)，并计算质询响应(共享令牌+质询)(835)。
服务提供商807基于从次级装置801发送的质询响应是否与由服务提供商807计算出的质询响应相同来验证次级装置801(837)。
例如，可以在服务提供商807、主装置803和次级装置801之间同步或预先确定共享令牌计算函数和质询响应计算函数。
如果针对次级装置801的验证结果成功，则服务提供商807向次级装置801提供DK(839)(13、提供服务(钥匙提供等)，(可选地)，如果存在访问属性，则提供反映了访问属性的服务)。
这里，如果访问属性在“1”操作处被设置，则服务提供商807提供反映了与所设置的访问属性相应的特征的DK。
同时，DK和访问属性可被存储在不同装置处或装置内的不同区域处。例如，DK可被存储在SE处，并且访问属性可被存储在单独的装置或区域(诸如TEE等)处。
将注意，图8中的数字钥匙提供处理是在基于次级装置共享数字钥匙的情况下的数字钥匙提供处理。
将注意，图8中的数字钥匙提供处理是根据如图3所述的数字钥匙提供处理的在服务提供商、主装置和次级装置之间的信号发送/接收操作。
尽管图8以一系列操作示出提供DK的处理，但是图8中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图9A和图9B是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图9A和图9B，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图9A和图9B以术语“OEM”、“所有者智能装置”和“客户端智能终端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图9A和图9B中提供数字钥匙的处理是基于次级装置共享数字钥匙的处理。
将注意，图9A和图9B中提供数字钥匙的处理是增强了主装置和次级装置之间的安全性的数字钥匙提供处理。
将注意，图9A和图9B中提供数字钥匙的处理是根据如图3所述的数字钥匙提供处理的在服务提供商、主装置和次级装置之间的信号发送/接收操作。
主装置903的应用904向服务提供商907发送请求钥匙共享服务的消息(911)(1、钥匙共享请求(所有者ID)、(可选的)访问属性)。请求钥匙共享服务的消息可包括ID(诸如主装置的标识符(即，所有者ID))等。用于请求钥匙共享服务的消息可以可选地包括诸如访问属性等的信息。
这里，访问属性可包括钥匙寿命、自动驾驶距离、与可以驾驶车辆的区域相关的信息(例如，地理围栏(例如，指示可以在特定区域驾驶车辆的信息))、车辆属性(例如，最大速度等)和车辆使用权限(例如，车门打开、后备箱打开、启动车辆等)。
服务提供商907向主装置903的应用904发送对钥匙共享请求的响应、随机数和服务ID(913)(2、钥匙共享响应(随机数，服务ID))。随机数可用于防止在主装置903中产生令牌的重复使用。当次级装置901请求钥匙提供(即，“7”操作)时，服务ID可用于在服务提供商907、主装置903和次级装置901之间匹配服务同步。
服务提供商907计算共享令牌，并且共享令牌是基于输入数据和共享的DK(如图9所示的DK.sharing)计算出的(915)(OEM计算Shr.Token＝f(输入数据，DK.sharing)&Hash)。
主装置903的应用904向主装置903的安全元件905发送用于命令执行安全操作的执行安全操作APDU命令(917)。安全操作可以是令牌产生操作。
在从主装置903的应用904接收到执行安全操作APDU命令时，主装置903的安全元件905使用存储在主装置903的安全元件905处的DK或具有与DK等同权限的钥匙来产生共享令牌(919)。可基于DK或具有与DK等同权限的钥匙并基于从服务提供商907提供的随机数来产生共享令牌。
主装置903的安全元件905向主装置903的应用904发送包括产生的共享令牌的响应(921)。(3、执行安全操作APDU：令牌产生操作；4、Shr.Token＝Hash(输入数据，DK.sharing)；5、rsp.(Shr.Token))。
然后，在次级装置901和主装置903之间建立基于短程通信方案(诸如NFC、蓝牙等)的通信环境(923)。在图9A和9B中，将假设在次级装置901和主装置903之间建立基于NFC方案的通信环境。也就是说，在图9A和9B中，将假设在次级装置901和主装置903之间建立NFC连接(NFC连接建立)。因此，将假设在次级装置901和主装置903之间产生安全信道。
在次级装置901和主装置903的应用904之间执行用于安全通信的密钥交换过程(925)。用于安全通信的密钥交换过程可包括凭证交换过程、PK交换过程、基于密钥共享算法的密钥交换过程等。主装置903的应用904对共享令牌进行加密(927)。主装置903的应用904向次级装置901发送服务ID和经过加密的共享令牌(929)(7、发送ShrToken和服务ID)。
在从主装置903的应用904接收到共享令牌和服务ID时，次级装置901通过对经过加密的共享令牌进行解码来获得共享令牌(931)。
次级装置901向服务提供商907请求DK共享(933)(9、钥匙共享请求(服务ID))。
服务提供商907可通过服务ID识别出次级装置901已连接到哪个主装置等。
服务提供商907向次级装置901发送请求对共享令牌进行验证的共享令牌验证请求(935)(10、ShrToken验证请求(质询))。这里，共享令牌验证请求可包括质询。
服务提供商907请求对共享令牌进行验证以检查次级装置901是否具有由主装置903产生的共享令牌。
在从服务提供商907接收到共享令牌验证请求时，次级装置901计算质询响应(937)，并向服务提供商907发送计算出的质询响应(939)(11、计算质询响应＝f(ShrToken，质询)；12、质询响应)。可基于(由主装置903提供的)共享令牌和(由服务提供商907提供的)质询来产生质询响应。
服务提供商907知道随机数的值和质询的值，并可通过所有者ID知道主装置903使用哪个DK。
服务提供商907基于所述值计算共享令牌(随机数+DK)(915)，并计算质询响应(共享令牌+质询)(941)。服务提供商907对从次级装置901接收的质询响应进行验证(943)(13、由OEM计算质询响应＝f(ShrToken_by OEM，质询))；14、由OEM通过与质询响应进行比较来对质询响应进行验证)。
服务提供商907基于从次级装置901发送的质询响应与由服务提供商907计算的质询响应是否相同来验证次级装置901(943)。
例如，可以在服务提供商907、主装置903和次级装置901之间同步或预先确定共享令牌计算函数和质询响应计算函数。
如果针对次级装置901的验证结果成功，则服务提供商907向次级装置901提供DK(945)(15、提供服务(钥匙提供等)，(可选地)，如果存在访问属性，则提供反映了访问属性的服务)。
这里，如果访问属性在“1”操作处被设置，则服务提供商907提供反映了与所设置的访问属性相应的特征的DK。
DK和访问属性可被存储在不同装置处或装置内的不同区域处。例如，DK可被存储在SE处，并且访问属性可被存储在单独的装置或区域(诸如TEE)。
尽管图9A和图9B将提供DK的处理示出为一系列操作，但是图9A和9B中的各种操作可重叠、并行发生、以不同的顺序发生或多次发生。
图10A和图10B是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图10A和图10B，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图10A和图10B以术语“OEM”、“所有者智能装置”和“客户端智能终端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图10A和图10B中提供数字钥匙的处理是基于次级装置共享数字钥匙的处理。
将注意，图10A和图10B中提供数字钥匙的处理是添加了通过主装置进行重新确认过程的数字钥匙提供处理。
将注意，图10A和图10B中提供数字钥匙的处理是根据如图3所述的数字钥匙提供处理的在服务提供商、主装置和次级装置之间的信号发送/接收操作。
主装置1003的应用1004向服务提供商1007发送用于请求钥匙共享服务的消息(1011)(1、钥匙共享请求(所有者ID)，(可选的)访问属性)。请求钥匙共享服务的消息可包括ID(诸如主装置的标识符(即，所有者ID))等。用于请求钥匙共享服务的消息可以可选地包括诸如访问属性等的信息。
这里，访问属性可包括钥匙寿命、自动驾驶距离、与可以驾驶车辆的区域相关的信息(例如，地理围栏(例如，指示可以在特定区域驾驶车辆的信息))、车辆属性(例如，最大速度等)和车辆使用权限(例如，车门打开、后备箱打开、启动车辆等)。
服务提供商1007向主装置1003的应用1004发送对钥匙共享请求的响应、随机数和服务ID(1013)(2、钥匙共享响应(随机数，服务ID))。随机数可用于防止在主装置1003中产生令牌的重复使用。当次级装置1001请求钥匙提供(即，“7”操作)时，服务ID可用于在服务提供商1007、主装置1003和次级装置1001之间匹配服务同步。
主装置1003的应用1004向主装置1003的安全元件1005发送用于命令执行安全操作的执行安全操作APDU命令(1017)。安全操作可包括令牌产生操作。
在从主装置1003的应用1004接收到执行安全操作APDU命令时，主装置1003的安全元件1005使用存储在主装置1003的安全元件1005处的DK或具有与DK等同权限的钥匙来产生共享令牌(1019)。可基于DK或具有与DK等同权限的钥匙并基于从服务提供商1007提供的随机数来产生共享令牌。
主装置1003的安全元件1005向主装置1003的应用1004发送包括产生的共享令牌的响应(1021)。(3、执行安全操作APDU：令牌产生操作；4、Shr.Token＝f(输出数据，DK.sharing)&Hash；5、rsp.(Shr.Token))。
然后，在次级装置1001和主装置1003之间建立基于短程通信方案(诸如NFC、蓝牙等)的通信环境(1023)。在图10A和图10B中，将假设在次级装置1001和主装置1003之间建立基于NFC方案的通信环境。也就是说，在图10A和图10B中，将假设在次级装置1001和主装置1003之间建立NFC连接(NFC连接建立)。也就是说，在次级装置1001和主装置1003之间产生安全信道。
在次级装置1001和主装置1003的应用1004之间执行用于安全通信的密钥交换过程(1025)。用于安全通信的密钥交换过程可包括凭证交换过程、PK交换过程、基于密钥共享算法的密钥交换过程等。可以可选地执行用于安全通信的密钥交换过程。
主装置1003的应用1004对共享令牌进行加密(1027)。这里，也可以可选地执行共享令牌的加密。
主装置1003的应用1004向次级装置1001发送服务ID和经过加密的共享令牌(1029)(7、发送ShrToken和服务ID)。
在从主装置1003的应用1004接收到共享令牌和服务ID时，次级装置1001通过对经过加密的共享令牌进行解码来获得共享令牌(1031)。这里，可以可选地执行对经过加密的共享令牌进行解码的操作。
次级装置1001向服务提供商1007请求数字钥匙共享(1033)(9、钥匙共享请求(服务ID和共享令牌))。
服务提供商1007可通过服务ID识别出次级装置1001已连接到哪个主装置等。
服务提供商1007向主装置1003的应用1004发送请求对共享令牌进行验证的共享令牌验证请求(1035)(10、ShrToken验证请求(ShrToken))。这里，共享令牌验证请求包括共享令牌。
在从服务提供商1007接收到共享令牌验证请求时，主装置1003的应用1004向主装置1003的安全元件1005发送用于命令执行安全操作的APDU命令(例如，执行安全操作APDU命令)(1037)。这里，执行安全操作APDU命令是用于请求对共享令牌进行验证的APDU命令。
在从主装置1003的应用1004接收到执行安全操作APDU命令时，主装置1003的安全元件1005对共享令牌执行验证操作，并向主装置1003的应用1004发送包括验证操作的结果的验证结果(1039)。这里，可以可选地执行发送执行安全操作APDU命令的操作和发送验证结果的操作。
主装置1003的应用1004向服务提供商1007发送共享令牌的验证结果(1041)。
如果针对次级装置1001的验证结果成功，则服务提供商1007向次级装置1001提供DK(1043)(15、提供服务(钥匙提供等)，(可选地)，如果存在访问属性，则提供反映了访问属性的服务)。这里，如果访问属性在“1”操作处被设置，则服务提供商1007提供反映了与所设置的访问属性相应的特征的DK。
DK和访问属性可被存储在不同装置处或装置内的不同区域处。例如，DK可被存储在SE处，并且访问属性可被存储在单独的装置或区域(诸如TEE)。
尽管图10A和图10B将提供DK的处理示出为一系列操作，但是图10A和10B中的各种操作可重叠、并行发生、以不同的顺序发生或多次发生。
图11示意性地示出根据本公开的另一实施例的在通信系统中提供DK的处理。
参照图11，将注意，服务提供商被示出为“服务提供商”，主装置被示出为“被授权的实体(所有者)”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图11以术语“服务提供商”、“被授权的实体(所有者)”和“客户端智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置1101向服务提供商1107请求服务(1111)(1、服务请求(钥匙共享、安全共享等))。这里，将在下面描述服务的种类。
服务的种类可包括诸如以下服务：(1)接收其他装置的主要信息(诸如钥匙共享等)的服务(例如，在本公开的各种实施例中的接收用于共享钥匙的主要信息的服务)，(2)在主装置1103的许可下使用次级装置没有直接订阅的服务的服务，以及(3)想要通过服务提供商安全地接收主装置1103的主要信息(例如，凭证、ID、密码(PW)等)的服务。
服务提供商1107向次级装置1101传送安全服务访问信息(1113)(2、传送服务访问信息(N/W访问信息、服务器URL、服务ID等))。这里，服务访问信息可包括暂时可用的N/W访问信息、服务相关的服务URL、服务ID等。
服务提供商1107可预先执行进行检查的操作(诸如是否已在次级装置1101上进行刷机(rooting)、应用是否是可信应用等)。
当在主装置1103和次级装置1101之间建立了NFC连接(NFC连接建立)时，次级装置1101向主装置1103请求服务许可(例如，钥匙共享、信息共享、登录许可等)(1117)(3、信息共享请求(服务访问信息、客户端ID))。
次级装置1101可发送从服务提供商1107接收的服务访问信息。也就是说，次级装置1101可发送包括服务访问信息和次级装置1101的ID(即，客户端ID)的服务许可请求。
主装置1103基于从次级装置1101接收的服务访问信息来访问服务提供商1107(1119)(4、基于服务访问信息的服务器访问)。
在主装置1103和服务提供商1107之间执行用于认证主装置1103的过程。也就是说，服务提供商1107对主装置1103进行验证以验证服务提供商1107是否可允许服务(1121)(5、所有者认证(账户认证、数字钥匙认证等))。例如，服务提供商1107可通过检查DK是否被存储在主装置1103处来对主装置1103进行验证。这在假设服务提供商1107和主装置1103共享DK的情况下是可行的。
可选地，服务提供商1107可通过检查主装置1103是否是已经订阅服务提供商1107的服务的用户或在服务提供商1107的服务处被注册的用户来对主装置1103进行验证。这在假设信息被发送并且服务被许可的情况下是可行的。
服务提供商1107和主装置1103可另外地执行要求主装置1103的用户的同意的操作，诸如由用户输入确认按钮的操作、认证指纹的操作等。
如果存在将与次级装置1101共享的信息，则主装置1103向服务提供商1107发送所述信息(1123)(6、传送将共享的安全信息(例如，访问属性或安全信息))。
服务提供商1107提供次级装置1101请求的信息和服务，并且主装置1103向次级装置1101确认(1125)(7、传送安全信息)。
情况1：如果主要信息(诸如凭证)存储在主装置1103处，则主装置1103将主要信息上传到服务提供商1107。
情况2：在DK共享时，主装置1103向服务提供商1101发送钥匙ID、钥匙属性等，其中，服务提供商1107向次级装置1101提供与标准相应的DK。
情况3：如果服务提供商1107仅需要提供特定服务(例如，音乐收听服务等)，则可省略操作“6”，并且在如操作“5”所述的针对次级装置1101的认证之后立即提供服务。
将注意，图11中的数字钥匙提供处理是根据如图4所述的数字钥匙提供处理的在服务提供商、主装置和次级装置之间的信号发送/接收操作。
用于识别次级装置的信息(诸如电话号码、IMEI，SE ID等)是唯一的，但是任何人都可以产生并获得该信息。因此，即使主装置接收次级装置的次级装置标识信息，也不存在针对次级装置标识信息的比较目标，因此可能难以对次级装置标识信息进行验证。
因此，根据本公开的实施例，将主装置的GPS信息与次级装置的GPS信息进行比较。验证主装置的GPS信息和次级装置的GPS信息，并基于主装置和次级装置之间的同时性(例如，诸如时间和位置的同时性)来对次级装置进行认证。
此外，通过两个不同的路径获得次级装置ID，并且比较通过所述两个不同路径获得的次级装置ID，因此可增强针对次级装置的验证。
图12示出根据本公开的实施例的在通信系统中验证次级装置的位置的处理。
在图12中的对次级装置的位置进行的验证操作中，除了次级装置以外，诸如GPS信息、时间戳等的附加信息也在DK共享处理期间被注册，主装置和次级装置检查主装置和次级装置是否存在于相同的区域并共享DK，因此可以提供针对安全攻击(诸如中间人攻击等)更鲁棒的DK共享服务。
参照图12，当主装置和次级装置选择钥匙共享服务(1、运行App(选择钥匙共享))时，执行敲击过程(2、敲击)，主装置在内部获得在敲击时间点的GPS信息和绝对时间(3、内部获得在敲击时间点的GPS信息和绝对时间(参考时间、参考GPS信息))。
次级装置获得次级装置的用户信息以及在敲击时间点的绝对时间和GPS信息(4、获得信息(SE ID、客户端凭证)+在敲击时间点的GPS信息和绝对时间)。次级装置向主装置发送次级装置的用户信息，并且绝对时间和GPS信息被一起发送(5、传送客户端信息(SEID、客户端凭证、时间、GPS信息))。
主装置将主装置的参考时间和参考GPS信息与从次级装置接收的时间和GPS信息进行比较(6、将参考时间和参考GPS信息与客户端的时间和GPS信息进行比较，并对客户端的时间和GPS信息进行验证)。如果次级装置和主装置存在于同一区域中，则主装置使用主装置的DK对主装置的用户信息进行签名(7、使用DK签名)，并在服务提供商处注册签名的用户信息(8、代替注册)。
图13是示出根据本公开的实施例的通信系统中的主装置的操作处理的流程图。
参照图13，将注意，主装置被示出为“所有者”，次级装置被示出为“客户端”，并且敲击被执行的时间点的绝对时间被示出为“时间戳”。此外，将注意，图13以术语“所有者”和“客户端”可与术语“主装置”和“次级装置”互换的形式被示出。在图13中，对GPS信息和时间戳进行验证的操作可以在例如在DK提供处理中执行的次级装置注册处理中的所有者预确认操作处被执行。
在操作1311，主装置获得主装置的信息(例如，GPS信息和GPS时间戳)，并进行到操作1313。这里，将假设主装置的GPS信息是“GPS_O”，主装置的GPS时间戳是“To”。在操作1313，主装置获得次级装置的信息(例如，GPS信息和GPS时间戳)，并进行到操作1315。这里，将假设次级装置的GPS信息是“GPS_C”，并且次级装置的GPS时间戳是“Tc”。
在操作1315，主装置确定主装置的GPS信息与次级装置的GPS信息之间的差是否小于阈值差值(例如，GSP_t)，以及主装置的GPS时间戳与次级装置的GPS时间戳之间的差是否小于另一阈值差值(例如，Tt)。
如果主装置的GPS信息与次级装置的GPS信息之间的差不小于GSP_t，或者主装置的GPS时间戳与次级装置的GPS时间戳之间的差不小于Tt，则主装置进行到操作1317。在操作1317，主装置确定针对次级装置的认证失败。
然而，如果主装置的GPS信息与次级装置的GPS信息之间的差小于GSP_t，并且主装置的GPS时间戳与次级装置的GPS时间戳之间的差小于Tt，则主装置进行到操作1319。在操作1319，主装置确定是否执行了主装置确认。
如果执行了主装置确认，则主装置进行到操作1321。主装置向安全元件传送次级装置的信息，并且使用DK来对次级装置的信息进行签名以进行操作1321。
图14是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图14，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图14以术语“OEM”、“所有者智能装置”和“客户端智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图14中的数字钥匙提供处理包括：在主装置中产生和传送与认证有关的信息的处理。
首先，例如，在次级装置1401和主装置1403之间建立NFC连接(1411)。次级装置1401向主装置1403的应用1404发送次级装置1401的信息(例如，SE ID、次级装置1401的PK(Client.pk)、GPS信息和时间戳)(1413)。次级装置1401可以可选地向主装置1403的应用1404发送关于用于发送令牌的第二连接的信息。
主装置1403的应用1404对从次级装置1401发送的次级装置信息、GPS信息和时间戳执行验证操作(1415)，并在主装置1403中执行用户确认操作(1417)。可以可选地执行用户确认操作。
然后，通过OMAPI在主装置1403的应用1404和主装置1403的安全元件1405之间建立信道(1419)，并且主装置1403的应用1404向主装置1403的安全元件1405发送执行安全操作APDU命令(1421)。执行安全操作APDU命令可包括用于请求计算数字签名的命令。
主装置1403的安全元件1405基于输入数据和共享的DK(DK.sharing)来计算DS(1423)。输入数据可包括DK ID和次级装置1401的信息。
主装置1403的安全元件1405向主装置1403的应用1404发送包括计算出的数字签名的响应(1425)。主装置1403的应用1404向服务提供商1407发送次级装置注册请求(1427)。次级装置注册请求包括次级装置信息、数字签名和DK标识符，并且可以可选地包括访问属性。
服务提供商1407对数字签名进行验证(1429)，并计算次级装置1401的OTP，即，ClientOTP(1431)。可基于次级装置1401的SHS和PK产生次级装置1401的OTP(ClientOTP＝enc(SHS，Client.pk))。
服务提供商1407向主装置1403的应用1404发送包括次级装置1401的OTP的响应(1433)。主装置1403的应用1404重新建立与次级装置1401的第二连接(1435)，并向次级装置1401发送次级装置1401的OTP(1437)。
尽管图14将提供DK的处理示出为一系列操作，但是图14中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
如上所述，执行对次级装置的认证以便获得信息源的可靠性并对应用的完整性进行验证。
可存在对应用的完整性进行验证的各种方案。例如，可通过服务提供商对应用的完整性进行验证。在这种情况下，服务提供商单独地操作用于应用认证的服务器，这可能增加服务操作和管理成本。
在另一种方案中，可以在没有服务提供商的情况下在装置之间对应用的完整性进行验证。在这种情况下，装置(即，主装置和次级装置)的操作系统(OS)和应用的版本应该是相同的。例如，主装置可以在接收到次级装置的散列(hash)值之后，通过将次级装置的散列值与主装置的散列值进行比较来对应用的完整性进行验证。在该方案中，应考虑诸如装置制造商、OS、装置类型等的各种参数，这可能难以实现。
因此，根据本公开的实施例，提供了一种用于对信息可靠性直接进行验证的方案。也就是说，主装置可通过直接获得并验证存储在SE处的信息来增强信息的可靠性。为方便起见，该验证方案将被称为双向验证方案。
图15示出根据本公开的实施例的在通信系统中对次级装置进行验证的处理。
参照图15，将注意，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图15以术语“所有者”和“客户端”可与术语“主装置”和“次级装置”互换的形式被示出。
如果双向验证方案被实现，则主装置可从次级装置的应用和次级装置的SE中的每一个获得SE ID，对SE ID进行比较，绑定次级装置的应用和次级装置的SE，以便在服务提供商处注册绑定的应用和SE。
更具体地，可以在DK共享处理期间通过存在于OS区域中的移动UI(＝应用)来获得用户信息。因此，如果在OS上进行了刷机或者OS被黑客攻击感染等，则从应用发送的用户信息的可靠性可能较低。因此，用户安全元件直接获得未通过移动UI传递的主要信息，并将获得的主要信息与通过用户应用获得的信息进行比较，以便将该结果用于对用户应用的附加验证。
主装置和次级装置运行应用以选择钥匙共享(1、运行应用(选择钥匙共享))，次级装置产生次级装置信息(产生客户端信息(应用的SE ID、凭证、GPS信息等)。次级装置向主装置发送产生的次级装置信息(3、传送客户端信息)，主装置读取存储在次级装置的安全元件处的次级装置的SE ID(4、读取客户端的SE的SE ID)。
主装置的应用将应用的SE ID与安全元件的SE ID进行比较(5、将应用的SE ID与SE的SE ID进行比较)，并将主装置的GPS信息与次级装置的GPS信息进行比较(7、比较GPS信息)。主装置的应用对次级装置的凭证进行验证(6、验证凭证)，主装置的安全元件基于数字钥匙对SE ID和凭证进行签名(8、使用DK签名(SE ID+凭证))。
主装置代替次级装置在服务提供商(图15中未示出)处注册次级装置的SE ID和凭证。
图16A和图16B是示出根据本公开的实施例的根据通信系统中的对次级装置进行验证的处理的信号发送/接收处理的信号流图。
参照图16A和图16B，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图16A和图16B以术语“OEM”、“所有者智能装置”和“客户端智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
首先，例如，在次级装置1601和主装置1603之间建立NFC连接(1611)。次级装置1601的应用1606向主装置1603的应用1604发送次级装置1601的信息(例如，次级装置1601的SE ID和PK(Client.pk))(1613)。次级装置1601的应用1606可以可选地向主装置1603的应用1604发送GPS信息、时间戳和关于用于发送令牌的第二连接的信息。
在次级装置1601的安全元件1602和主装置1603的应用1604之间建立第二连接(1615)，主装置1603的应用1604向次级装置1601的安全元件1602发送GETDATA PDU请求。
次级装置1601的安全元件1602向主装置1603的应用1604发送对GETDATA APDU请求的响应(1619)。所述响应可包括次级装置1601的安全元件1602的SE ID。
主装置1603的应用1604对从次级装置1601的安全元件1602发送的次级装置信息和SE ID执行验证操作(1621)，并对GPS信息和时间戳信息执行验证操作。可以可选地执行针对GPS信息和时间戳信息的验证操作。主装置1603的应用1604执行用户确认操作(1625)。然后，通过OMAPI在主装置1603的应用1604和主装置1603的安全元件1605之间建立信道，并且主装置1603的应用1604向主装置1603的安全元件1605发送执行安全操作APDU命令(1629)。执行安全操作APDU命令可包括用于请求计算数字签名的命令。
主装置1603的安全元件1605基于输入数据和共享的DK(DK.Sharing)来计算DS(1631)。输入数据可包括次级装置1601的信息和DK ID。
主装置1603的安全元件1605向主装置1603的应用1604发送包括计算出的数字签名的响应(1633)。主装置1603的应用1604向服务提供商1607发送次级装置注册请求(1635)。这里，次级装置注册请求包括次级装置信息、数字签名和DK ID，并且可以可选地包括访问属性。
服务提供商1607对数字签名进行验证(1637)，并计算用于次级装置1601的OTP，即，ClientOTP(1639)。可基于次级装置1601的SHS和PK来产生用于次级装置1601的OTP(ClientOTP＝enc(SHS，Client.pk))。
服务提供商1607向主装置1603的应用1604发送包括次级装置1601的OTP的响应(1641)。主装置1603的应用1604重新建立与次级装置1601的第二连接(1643)，并向次级装置1601的应用1606发送次级装置1601的OTP(1645)。
尽管图16A和图16B将信号发送/接收处理示出为一系列操作，但是图16A和图16B中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
在DK提供处理期间用于计算数字签名的APDU命令可如下表1中所示被表示。
表1
Figure GDA0002138630260000341
Figure GDA0002138630260000351
(1)CLA:命令消息的类型字节
(2)INS：指令字节
(3)P：参考控制参数
(4)Lc：数据字段的长度
在用于计算数字签名的APDU命令中，数据字段可如下表2中所示被表示。
表2
Figure GDA0002138630260000352
包括在对用于计算数字签名的APDU命令的响应消息(即，APDU响应)中的数据字段可如下表3中所示被表示。
表3
Figure GDA0002138630260000353
计算数字签名时的错误情况可如下表4所示被表示。
表4
SW1 SW2 含义
‘6A’ ‘80’ 命令数据中的不正确值
‘6A’ ‘81’ 不支持的功能
‘6A’ ‘XX’ 未找到数字钥匙对象
在DK提供处理中，用于产生令牌的APDU命令可如下表5中所示被表示。
表5
Figure GDA0002138630260000354
Figure GDA0002138630260000361
(1)CLA:命令消息的类型字节
(2)INS：指令字节
(3)P：参考控制参数
(4)Lc：数据字段的长度
在用于产生令牌的APDU命令中，数据字段可如下表6中所示被表示。
表6
Figure GDA0002138630260000362
包括在对用于产生令牌的APDU命令的响应消息(即，APDU响应)中的数据字段可如下表7中所示被表示。
表7
Figure GDA0002138630260000363
产生令牌时的错误情况可如下表8中所示被表示。
表8
SW1 SW2 含义
‘6A’ ‘80’ 命令数据中的不正确值
‘6A’ ‘81’ 不支持的功能
‘6A’ ‘XX’ 未找到数字钥匙对象(被授权的实体)
在DK提供处理中，用于验证令牌的APDU命令可如表9中所示被表示。
表9
Figure GDA0002138630260000364
Figure GDA0002138630260000371
(1)CLA:命令消息的类型字节
(2)INS：指令字节
(3)P：参考控制参数
(4)Lc：数据字段的长度
在用于验证令牌的APDU命令中，数据字段可如下表10中所示被表示。
表10
Figure GDA0002138630260000372
验证令牌时的错误情况可如下表11中所示被表示。
表11
SW1 SW2 含义
‘6A’ ‘80’ 命令数据中的不正确值
‘6A’ ‘81’ 不支持的功能
‘6A’ ‘XX’ 未找到数字钥匙对象(被授权的实体)
图17是示出根据本公开的实施例的通信系统中的主装置和次级装置之间的连接处理的信号流图。
参照图17，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图17以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
首先，如果主装置和次级装置之间的距离相对较短(例如，如果距离短于预设的第一距离)，则可以通过NFC建立安全连接。
如果主装置和次级装置之间的距离相对较长(例如，如果距离大于或等于预设的第一距离)，则可使用OTP执行相互发现，并可通过应用标识符(App ID)建立安全连接。可使用除NFC之外的各种连接方案，诸如蓝牙、Wi-Fi等。
次级装置1705安装应用(1711)，并向服务提供商1701发送次级装置1705的PK、凭证、电话号码和IMEI(1713)。服务提供商1701注册次级装置1705和应用ID(1715)。
主装置1703向次级装置1705发送短消息服务(SMS)，其中，所述短消息服务(SMS)指明服务提供商1701指示次级装置1705提供DK(1717)。SMS包括次级装置1705的OTP。主装置1703向服务提供商1701请求针对次级装置1705的连接信息(1719)。针对次级装置1705的连接信息请求可包括次级装置1705的OTP和电话号码。
在接收到针对次级装置1705的连接信息请求时，服务提供商1701确认次级装置1705的注册(1721)。次级装置1705发送指示次级装置1705接收到SMS和次级装置1705的OTP的信息，其中，该SMS指明服务提供商1701指示提供DK(1723)。服务提供商1701基于OTP将主装置1703和次级装置1705进行匹配(1725)，并向主装置1703发送指示次级装置1705正常注册的确认消息和次级装置应用ID(1727)。主装置1703与次级装置1705建立安全IP连接(1729)。这里，基于次级装置应用ID来建立安全IP连接。
尽管图17将主装置和次级装置之间的连接处理示出为一系列操作，但是图17中的各种操作可重叠、并行发生、以不同顺序发送或多次发生。
图18是示出根据本公开的实施例的在通信系统中注册次级装置的处理的信号流图。
参照图18，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图18以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。在图18中，PK表示公共密钥，SK表示秘密密钥(即，私有密钥)。
将注意图18中的次级装置注册处理是在存在客户端应用(CA)的情况下基于CA凭证来担保主装置的状况下的次级装置注册处理。
在服务提供商1801和主装置1803之间执行PK交换过程和凭证交换过程(1811)。服务提供商1801存储主装置1803的PK(即，PK.Owner)(1813)，并为主装置1803提供DK(1815)。主装置1803向次级装置1805发送指示主装置将发起发送DK的操作的钥匙传送发起消息。这里，钥匙传送发起消息可包括主装置1803的证书(例如，CERT.Owner)。
在接收到钥匙传送发起消息时，次级装置1805通过检查次级装置1805的能力来确定是否使用eSE(1819)。如果可以使用eSE，则次级装置1805向主装置1803发送发起响应消息(1821)。发起响应消息可包括次级装置1805的证书(例如，CERT.Client)。
在从次级装置1805接收到发起响应消息时，主装置1803向次级装置1805请求次级装置1805的信息(1823)。也就是说，主装置1803向次级装置1805发送次级装置信息请求。这里，次级装置信息请求可包括会话ID。
在从主装置1803接收到次级装置信息请求时，次级装置1805产生针对次级装置1805的次级装置信息(1825)。次级装置信息可包括针对次级装置1805的次级装置PK(即，Client.PK)、凭证和针对次级装置ID的信息。针对次级装置ID的信息可包括次级装置ID、次级装置应用ID、IEMI、eSE ID、电话号码等。
次级装置1805向主装置1803发送对次级装置信息请求的响应(1827)。这里，所述响应包括次级装置信息和会话ID。
在接收到所述响应时，主装置1803通过使用主装置1803的SK(即，SK.Owner)对次级装置信息进行签名来担保次级装置信息的可靠性(1829)。主装置1803向服务提供商1801发送次级装置信息，并请求提供次级装置密钥(1831)。这里，次级装置密钥提供请求包括会话ID和主装置1803的签名。在从主装置1803接收到次级装置信息和次级装置密钥提供请求时，服务提供商1801检查主装置1803的签名是否是服务提供商1801已对其提供了DK的主装置的签名(1833)。如果主装置1803的签名与服务提供商1801已对其提供了DK的主装置的签名相同，则服务提供商1801确认并注册次级装置信息，并获得次级装置1805的PK(即，PK.Client)(1835)。
尽管图18将注册次级装置的处理示出为一系列操作，但是图18中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图19是示出根据本公开的实施例的在通信系统中注册次级装置的处理的信号流图。
参照图19，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图19以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。在图19中，PK表示公共密钥，SK表示秘密密钥(即，私有密钥)。
将注意，图19中的次级装置注册处理是在存在CA的情况下基于数字钥匙(DK)注册次级装置的处理。
服务提供商1901向主装置1903提供DK(1911)。主装置1903向次级装置1905发送指示主装置将发起发送DK的操作的钥匙传送发起消息。钥匙传送发起消息可包括主装置1903的证书(例如，CERT.Owner)。
在接收到钥匙传送发起消息时，次级装置1905通过检查次级装置1905的能力来确定是否使用eSE(1915)。如果可以使用eSE，则次级装置1905向主装置1903发送发起响应消息(1917)。发起响应消息可包括次级装置1905的证书(例如，CERT.Client)。
在从次级装置1905接收到发起响应消息时，主装置1903向次级装置1905请求次级装置1905的信息(1919)。也就是说，主装置1903向次级装置1905发送次级装置信息请求。次级装置信息请求可包括会话ID。
在从主装置1903接收到次级装置信息请求时，次级装置1905产生针对次级装置1905的次级装置信息(1921)。次级装置信息可包括针对次级装置1905的次级装置PK(即，Client.PK)、凭证和针对次级装置ID的信息。针对次级装置ID的信息可包括次级装置ID、次级装置应用ID、IEMI、eSE ID、电话号码等。
次级装置1905向主装置1903发送对次级装置信息请求的响应(1923)。所述响应可包括次级装置信息和会话ID。
在接收到所述响应时，主装置1903对次级装置信息和DK进行散列(hash)(1925)，向服务提供商1901发送次级装置信息，并请求提供次级装置密钥(1927)。次级装置密钥提供请求可包括会话ID和主装置1903的签名。
在从主装置1903接收到次级装置信息和次级装置密钥提供请求时，服务提供商1901检查主装置1903的签名是否是服务提供商1901已对其提供了DK的主装置的签名(1929)。如果主装置1903的签名与服务提供商1901已对其提供了DK的主装置的签名相同，则服务提供商1901确认并注册次级装置信息，并获得次级装置1905的PK(即，PK.Client)(1931)。
尽管图19将注册次级装置的处理示出为一系列操作，但是图19中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图20A和图20B是示出根据本公开的实施例的在通信系统中注册次级装置的处理的信号流图。
参照图20A和图20B，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图20A和图20B以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。在图20A和图20B中，PK表示公共密钥，SK表示秘密密钥(即，私有密钥)。
将注意，图20A和图20B中的次级装置注册处理是基于用于认证数字钥匙权限的单独密钥来注册次级装置的处理。这里，用于认证数字钥匙权限的所述密钥是用于认证针对数字钥匙的权限的密钥。
在步骤2011中，服务提供商2001向主装置2003提供DK。
在接收到DK时，主装置2003产生用于认证DK的权限的密钥对(2013)。将假设用于认证数字钥匙的权限的密钥对是SK.DKConfirm和PK.DKConfirm。
主装置2003请求服务提供商2001注册PK.DKConfirm(2015)，并且服务提供商2001存储PK.DKConfirm(2017)。
主装置2003向次级装置2005发送指示主装置2003将发起发送DK的操作的钥匙传送发起消息(2019)。钥匙传送发起消息可包括主装置2003的证书(例如，CERT.Owner)。
在接收到钥匙传送发起消息时，次级装置2005通过检查次级装置2005的能力来确定是否使用eSE(2021)。如果可以使用eSE，则次级装置2005向主装置2003发送发起响应消息(2023)。发起响应消息可包括次级装置2005的证书(例如，CERT.Client)。
在步骤2025中，在从次级装置2005接收到发起响应消息时，主装置2003向次级装置2005请求次级装置2005的信息。也就是说，主装置2003向次级装置发送次级装置信息请求。次级装置信息请求可包括会话ID。
在从主装置2003接收到次级装置信息请求时，次级装置2005产生针对次级装置2005的次级装置信息(2027)。次级装置信息包括针对次级装置2005的次级装置PK(即，Client.PK)、凭证和针对次级装置ID的信息。针对次级装置ID的信息可包括次级装置ID、次级装置应用ID、IEMI、eSE ID、电话号码等。
次级装置2005向主装置2003发送对次级装置信息请求的响应(2029)。所述响应可包括次级装置信息和会话ID。
在接收到所述响应时，主装置2003通过使用SK.DKConfirm对次级装置信息进行签名来担保次级装置信息的可靠性(2031)。主装置2003向服务提供商2001发送次级装置信息，并请求提供次级装置密钥(2033)。次级装置密钥提供请求可包括会话ID和主装置2003的签名。
在从主装置2003接收到次级装置信息和次级装置密钥提供请求时，服务提供商2001使用PK.DKConfirm检查主装置2003的DK的权限和担保(2035)。
在步骤2037中，在检查主装置2003的DK的权限和担保之后，服务提供商2001确认并注册次级装置信息，并获得次级装置2005的PK(即，PK.Client)。
尽管图20A和图20B将注册次级装置的处理示出为一系列操作，但是图20A和图20B中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图21是示出根据本公开的实施例的在通信系统中注册次级装置的处理的信号流图。
参照图21，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图21以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。在图21中，PK表示公共密钥，SK表示秘密密钥(即，私有密钥)。
将注意，图21中的次级装置注册处理是在不存在CA的情况下基于用于次级装置接收数字钥匙的密钥来注册次级装置的处理。这里，用于次级装置接收数字钥匙的密钥可以用密钥对形式实现。
首先，在服务提供商2101和主装置2103之间共享PK、DK和/或专用DKConfirm(2111)。DKConfirm是用于验证DK权限的密钥。次级装置2105具有次级装置2105的DK证书(即，DKCERT.Client)。例如，DKCERT.Client可包括IMEI、eSEID等(2113)。
主装置2103向次级装置2105发送指示主装置2103将发起传送DK的操作的钥匙传送发起消息和次级装置信息请求(2115)。次级装置信息请求包括会话ID。
在接收到钥匙传送发起消息和次级装置信息请求时，次级装置2105通过检查次级装置2105的能力来确定是否使用eSE(2117)。如果可以使用eSE，则次级装置2105产生用于提供次级装置2105的DK(即，客户端DK)的密钥对(例如，SK.Client和PK.Client)(2119)。
次级装置2105产生针对次级装置2105的次级装置信息(2121)。次级装置信息包括针对次级装置2105的次级装置PK(即，PK.Client)、凭证和针对次级装置ID的信息。针对次级装置ID的信息可包括次级装置ID、次级装置应用ID、IEMI、eSE ID、电话号码等。
次级装置2105向主装置2103发送发起响应消息(2123)。发起响应消息包括次级装置2105的次级装置信息和会话ID。在从次级装置2105接收到发起响应消息时，主装置2103基于在主装置2103和服务提供商2101之间共享的信息来担保次级装置信息(2125)。次级装置信息包括次级装置2105的PK(即，PK.Client)。
主装置2103向服务提供商2101发送次级装置信息和次级装置密钥提供请求(2127)。次级装置密钥提供请求包括会话ID和主装置2103的担保信息。在从主装置2103接收到次级装置信息和次级装置密钥提供请求时，服务提供商2101检查从主装置2103接收的担保信息(2129)。如果担保信息是正常的，则服务提供商2101确认并注册次级装置信息，并获得次级装置2105的PK.Client(2131)。
尽管图21将注册次级装置的处理示出为一系列操作，但是图21中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图22是示出根据本公开的实施例的在通信系统中认证次级装置的处理的信号流图。
参照图22，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图22以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图22中对次级装置进行认证的处理是基于次级装置和服务提供商可能拥有的共享秘密密钥来对次级装置进行认证的处理。
首先，服务提供商2201产生凭证(2211)。可通过对PK.Client进行加密或者通过对SHS和PK.Client进行加密来产生凭证。
服务提供商2201向主装置2203发送针对次级装置2205的注册结果和凭证(2213)。会话ID可以与凭证一起发送。主装置2203指示次级装置2205向服务提供商2201请求钥匙提供并发送凭证(2215)。例如，主装置2203向次级装置2205发送会话ID，并且可以可选地发送服务提供商2201的表示服务提供商2201的PK的信息(例如，URL和PK.OEM)。
次级装置2205基于次级装置2205的SK(即，SK.CLient)获得SHS(2217)。次级装置2205基于针对服务提供商2201的访问信息向服务提供商2201请求次级装置密钥提供(2219和2221)。次级装置密钥提供请求可包括会话ID。
在从次级装置2205接收到次级装置密钥提供请求时，服务提供商2201向次级装置2205发送认证请求(2223)。所述认证请求包括质询。
在从服务提供商2201接收到认证请求时，次级装置2205向服务提供商2201发送对认证请求的认证响应(2225)。可通过对SHS和质询进行散列来产生认证响应。
尽管图22将对次级装置进行认证的处理示出为一系列操作，但是图22中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图23是示出根据本公开的实施例的在通信系统中对次级装置进行认证的处理的信号流图。具体地，图23示出基于次级装置和服务提供商可能拥有的共享秘密密钥来对次级装置进行认证的处理。
参照图23，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图23以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
首先，服务提供商2301产生凭证(2311)。可通过对PK.Client进行加密或者通过对SHS和PK.Client进行加密来产生凭证。
服务提供商2301向主装置2303发送针对次级装置2305的注册结果和凭证(2313)。会话ID可以与凭证一起发送。可选地，服务提供商2301的信息(例如，URL和PK.OEM)可额外发送到主装置2303。PK.OEM表示服务提供商2301的PK。
主装置2303指示次级装置2305向服务提供商2301请求钥匙提供并发送凭证(2315)。主装置2303向次级装置2305发送会话ID，并且可以可选地发送服务提供商2301的信息(例如，URL和PK.OEM)。
次级装置2305基于次级装置2305的SK(即，SK.Client)获得SHS(2317)。次级装置2305基于针对服务提供商2301的访问信息向服务提供商2301请求次级装置密钥提供(2319和2321)。次级装置密钥提供请求可包括会话ID。
在从次级装置2305接收到次级装置密钥提供请求时，服务提供商2301向次级装置2305发送认证请求(2323)。所述认证请求可包括质询。
在从服务提供商2301接收到认证请求时，次级装置2305向服务提供商2301发送对认证请求的认证响应(2325)。可通过对SHS和质询进行散列来产生认证响应。
尽管图23将对次级装置进行认证的处理示出为一系列操作，但是图23中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图24是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图24，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图24以术语“OEM”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
首先，服务提供商2401可直接向次级装置2405提供DK。
可选地，如图24中所示，在向次级装置2405提供DK的同时，服务提供商2401可暂时停止使用主装置2403的DK，这可具有与将物理钥匙从服务提供商2401发送到次级装置2405的操作相同的效果。
服务提供商2401请求次级装置2405存储DK(2411)，次级装置2405根据DK存储请求存储DK并向服务提供商2401发送存储结果(2413)。服务提供商2401向主装置2403发送DK禁用命令和针对次级装置2405的DK提供结果(2415)。存储DK的eSE的小应用程序被锁定并变得不可用(2417)。主装置2403向服务提供商2401发送DK的禁用结果(2419)。
服务提供商2401向次级装置2405发送DK禁用/删除命令(2421)。
在从服务提供商2401接收到DK禁用/删除命令时，次级装置2405向服务提供商2401发送针对DK禁用/删除命令的结果(2423)。服务提供商2401基于从次级装置2405接收的结果，向主装置2403发送DK启用命令以及针对次级装置2405的DK撤销结果(2425)。
在从服务提供商2401接收到DK撤销结果和DK启用命令时，主装置2403启用存储DK的eSE的小应用程序，因此eSE的小应用程序变得可用(2427)。主装置2403向服务提供商2401发送启用结果(2429)。
尽管图24将在通信系统中提供DK的处理示出为一系列操作，但是图24中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图25A和图25B是示出根据本公开的实施例的在通信系统中获得次级装置的信息的处理的信号流图。具体地，图25A和图25B示出通过包括在次级装置中的TEE来获得次级装置的信息的处理。
参照图25A和图25B中，将注意，服务提供商被示出为“OEM”，主装置被示出为“主智能装置”，并且次级装置被示出为“次级智能装置”。此外，将注意，图25A和图25B以术语“OEM”、“主智能装置”和“次级智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。将注意，图25A和图25B中获得次级装置的信息的处理是通过包括在次级装置中的可信执行环境(TEE)来获得次级装置的信息的处理。此外，可信应用(TA)表示安装在TEE处的应用。
首先，在主装置2501的应用2504和次级装置2505的应用2506之间产生NFC P2P会话(2511)，并且基于公共密钥匙基础设施(PKI)建立应用到应用安全信道(2513)。主装置2501的应用2504向次级装置2505的应用2506请求钥匙共享发起和次级装置信息(2515)。
次级装置2505的应用2506请求次级装置2505的TA以获得SE ID(2517)。次级装置2505的TA向次级装置2505的SE 2507请求SE ID(2519)，次级装置2505的SE 2507向TA传送SE ID(2521)。TA对次级装置信息进行签名(2523)，并向次级装置2505的应用2506传送包括已签名的次级装置信息的响应(2525)。次级装置信息包括SE ID、电话号码和次级装置2505的应用2506的秘密密钥(即，SApp.SK)。次级装置2505的应用2506向主装置2501的应用2504发送次级装置信息和次级装置2505的应用2506的证书(即，SApp.Cert)(2527)。SApp.Cert是基于服务提供商2508的SK(即，OEM.SK)和SApp.PK产生的。
主装置2501的应用2504使用SApp.PK对针对次级装置信息的签名进行验证(2529)，并对接收的电话号码执行用户确认(2531)。电话号码是通过TA获得的，以确保电话号码是可信的。
主装置2501的应用2504向主装置2501的DK小应用程序2502请求针对次级装置信息和SApp.Cert的DK签名(2533)。主装置2501的DK小应用程序2502使用DK对次级装置信息和SApp.Cert进行签名(2535)，并向主装置2501的应用2504发送签名结果(2537)。
主装置2501的应用2504向服务提供商2508请求钥匙共享服务，并发送DK签名(2539)。
服务提供商2508对DK签名进行验证(2541)，并且如果验证结果成功，则服务提供商2508通过对SApp.PK和个人识别码(PIN)进行加密来产生共享钥匙(即，Shr)(2543)。服务提供商2508向主装置2501的应用2504发送Shr(2545)。主装置2501的应用2504向次级装置2505的应用2506发送Shr(2547)。次级装置2505的应用2506请求TA注册临时PIN(2549)。TA提取并存储PIN(2551)，并向次级装置2505的应用2506发送PIN注册结果(2553)。TA的PIN提取可指示次级装置信息已正常地被发送到服务提供商2508。
次级装置2505的应用2506向服务提供商2508请求共享钥匙(2555)。共享钥匙请求可包括SE ID。
在接收到共享钥匙请求时，服务提供商2508向次级装置2505的应用2506发送用于请求对PIN进行验证的PIN验证请求(2557)。PIN验证请求可包括质询。
次级装置2505的应用2506请求TA对PIN进行验证(2559)。PIN验证请求可包括质询。
TA通过计算验证信息来对PIN进行验证(2561)，并向次级装置2505的应用2506发送验证结果(2563)。可基于PIN和质询来执行PIN验证，并且用于PIN验证的算法可基于服务提供商2508的属性。
次级装置2505的应用2506向服务提供商2508发送用于报告PIN已被验证的PIN验证报告(2565)。服务提供商2508确认PIN(2567)，并通过SE发放器/TSM来安装小应用程序(2569)。
尽管图25A和图25B将在通信系统中获得次级装置的信息的处理示出为一系列操作，但是图25A和图25B中的各种操作可重叠、并行发生、以不同顺序发生或多次发生。
图26A和26B是示出根据本公开的实施例的在通信系统中获得次级装置的信息的处理的信号流图。具体地，图26A和图26B示出通过TEE获得次级装置的信息并担保次级装置的用于DK共享的信息的处理。
参照图26A和图26B，将注意，服务提供商被示出为“OEM”，主装置被示出为“主智能装置”，并且次级装置被示出为“次级智能装置”。此外，将注意，图26A和图26B以术语“OEM”、“主智能装置”和“次级智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图26A和图26B中获得次级装置的信息的处理是通过TEE获得次级装置的信息并担保次级装置的用于数字钥匙共享的信息的处理。
首先，服务提供商2608将DK插入主装置2601的DK小应用程序2602(2611)。
服务提供商2608向主装置2601的应用2604触发用于DK共享服务的钥匙产生(2613)。主装置2601的应用2604请求主装置2601的TA产生用于数字钥匙共享的密钥对(2615)。
TA产生DK共享密钥对(即，P.Shr.SK和P.Shr.PK)(2617)，并向主装置2601的应用2604发送P.Shr.SK(2619)。
主装置2601的应用2604向服务提供商2608发送P.Shr.PK(2621)。
在主装置2601的应用2604和次级装置2605的应用2606之间产生NFC P2P会话(2625)，并且主装置2601的应用2604向主装置2601的TA通知钥匙共享发起(2627)。主装置2601的TA向主装置2601的应用2604传送用于钥匙共享所需的信息(即，包括P.Shr.PK的主装置信息)(2629)。
次级装置2605的应用2606向次级装置2605的TA发送所接收的主装置信息和SE ID获得请求(2630)。次级装置2605的TA从接收的主装置信息提取P.Shr.PK(2632)，并向次级装置2605的SE 2607请求SE ID(2633)。次级装置2605的SE 2607向TA传送SE ID(2635)。TA对次级装置信息进行签名，使用P.Shr.PK对经过签名的次级装置信息进行加密(2637)，并向次级装置2605的应用2606发送包括经过签名的次级装置信息的响应(2639)。次级装置信息包括次级装置2605的应用2606的秘密密钥(即，SApp.SK)、SE ID和电话号码。
次级装置2605的应用2606向主装置2601的应用2604发送次级装置信息和次级装置2605的应用2606的证书(即，SApp.Cert)(2641)。可基于服务提供商2608的SK(即，OEM.SK)和SApp.PK来产生SApp.Cert。
主装置2601的应用2604向主装置2601的TA发送接收的次级装置信息(2643)。主装置2601的TA使用P.Shr.SK对次级装置信息进行解码，从SApp.Certi获得SApp.PK，并使用SApp.PK对针对次级装置的签名进行验证(2645)。如果验证结果成功，则主装置2601的TA使用SApp.PK对次级装置信息和SApp.Cert进行签名(2647)，并向主装置2601的应用2604发送签名结果(2651)。
主装置2601的应用2604向服务提供商2608请求钥匙共享服务，并发送DK签名(2653)。
服务提供商2608对DK签名进行验证(2655)，并且如果验证结果成功，则通过对SApp.PK和PIN进行加密来产生共享钥匙(即，Shr)(2657)。可使用P.Shr.PK来执行DK签名验证。
服务提供商2608向主装置2601的应用2604发送Shr(2659)。主装置2601的应用2604向次级装置2605的应用2606发送Shr(2661)。
次级装置2605的应用2606请求TA注册临时PIN(2663)。TA提取并存储PIN(2665)，并向次级装置2605的应用2606发送PIN注册结果(2667)。TA的PIN提取指示次级装置信息已被正常发送到服务提供商2608。
在步骤2669中，次级装置2605的应用2606向服务提供商2608请求共享钥匙。共享钥匙请求可以包括SE ID。
在接收到共享钥匙请求时，服务提供商2608向次级装置2605的应用2606发送用于请求对PIN进行验证的PIN验证请求(2671)。PIN验证请求可包括质询。
次级装置2605的应用2606请求TA对PIN进行验证(2673)。PIN验证请求可包括质询。
TA通过计算验证信息来对PIN进行验证(2675)，并向次级装置2605的应用2606发送验证结果(2677)。可基于PIN和质询来执行PIN验证，并且用于PIN验证的算法可基于服务提供商2608的属性。
次级装置2605的应用2606向服务提供商2608发送用于报告PIN已被验证的PIN验证报告(2679)。服务提供商2608确认PIN(2681)，并通过SE发放器/TSM来安装小应用程序(2683)。
尽管图26A和图26B将在通信系统中获得次级装置的信息的处理示出为一系列操作，但是图26A和图26B中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图27示出根据本公开的实施例的在通信系统中提供DK的处理。
参照图27，将注意，服务提供商被示出为“OEM服务器”，主装置被示出为“所有者终端”，并且次级装置被示出为“客户端终端”。此外，将注意，图27以术语“OEM服务器”、“所有者终端”和“客户端终端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
首先，次级装置向主装置发送次级装置的次级装置信息([1])。
主装置通过在服务提供商和主装置之间共享的凭证信息来担保次级装置的可靠性，并在服务提供商处注册次级装置信息([2]和[3])。
服务提供商对主装置进行验证，注册次级装置的账户，并产生用于认证次级装置的OTP([4]、[5]和[6])。
用于认证的信息(即，由服务提供商产生的OTP)通过主装置被发送到次级装置([7]和[8])，从而在服务提供商2701和次级装置之间执行认证操作，并且服务提供商向次级装置提供钥匙([9])。
图28示出根据本公开的实施例的在通信系统中提供DK的处理。
具体地，图28示出与另一装置(例如，次级装置)共享主装置(或所有者装置)所拥有的DK的处理。主装置所拥有的DK的格式和提供给次级装置的DK的格式可根据服务提供商(例如，OEM)而改变。
DK的格式对于每个服务提供商也可以是唯一的，或者对于所有服务提供商可以是相同的。
图28中的DK提供处理可以是通过服务提供商进行的接近触发远程钥匙共享处理，其可称为“经由OEM后端的接近触发远程钥匙共享”。
在图28中，将注意，服务提供商被示出为“车辆OEM后端”，主装置被示出为“所有者”，并且次级装置被示出为“用户”。此外，将注意，图28以术语“车辆OEM后端”、“所有者”和“用户”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
参照图28，当次级装置(即，用户)位于主装置(即，所有者)附近时，即使次级装置未在服务提供商处或在由服务提供商提供的服务处注册，安全信息(例如，DK)仍可被发送到次级装置或者可与次级装置共享。
主装置和次级装置基于诸如NFC、蓝牙等的接近连接而连接。也就是说，在主装置和次级装置之间建立连接(1、连接建立)。
在建立连接之后，通过主装置在服务提供商处临时注册次级装置的用户信息(2、用户注册)。
在通过主装置在服务提供商处注册了次级装置的用户信息之后，当次级装置请求提供共享钥匙时，服务提供商验证次级装置(3、用户验证)。
如果针对次级装置的验证成功，则服务提供商基于数字钥匙服务部署和钥匙提供处理向次级装置传送数字钥匙。数字钥匙服务部署和钥匙提供处理可以是例如车辆连接联盟(CCC)数字钥匙服务部署和钥匙提供处理，并且此处将省略对数字钥匙服务部署和钥匙提供处理的详细描述(4、钥匙提供)。
图29A至图29C是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图。具体地，图29A至图29C指示次级装置和次级装置的用户信息如何在服务提供商处被注册。
在图29A至图29C中，将注意，服务提供商被示出为“车辆OEM后端”，主装置被示出为“所有者装置(DKS客户端)”，并且次级装置被示出为“用户装置”(DKS服务器)”。此外，将注意，图29A至图29C以术语“车辆OEM后端”、“所有者装置(DKS客户端)”和“用户装置(DKS服务器)”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置包括SE和移动UI，并且主装置包括移动UI和SE。在图29A至图29C中，为方便起见，包括在次级装置中的SE和移动UI将分别被称为“SE-A”和“移动UI-A”，并且包括在主装置中的SE和移动UI将分别被称为“SE-B”和“移动UI-B”。移动UI-A和移动UI-B可分别访问SE-A和SE-B。也就是说，移动UI表示能够与其他装置进行P2P通信并可访问SE的实体。
首先，激活移动UI-B(所有者移动UI的激活)，这将在下面描述。
移动UI-B根据应用启动、刷机检查(rooting check)等运行(a、启动应用和刷机检查)，并且诸如钥匙传送、钥匙共享等的菜单被选择(b、选择“共享我的钥匙”)。可以在运行应用时或者在根据服务开发需要特定功能时执行应用刷机检查。
如果根据移动UI-B的提供商或服务提供商的服务策略必要的话，则可执行用户认证处理(c、用户认证)，并可基于生物特征、已提前在主装置处注册的PIN等执行用户认证处理。移动UI-B开始在NFC P2P模式下操作(d、开始NFC P2P操作)。
在移动UI-B的激活处理中，除了刷机检查之外的其余操作可以是可选的，因此可根据移动UI-B的提供商的实现来执行或省略所述其余操作。移动UI-B支持一个或更多个应用刷机检查机制(移动UI应支持一个或更多个应用刷机检查机制)。
此外，激活移动UI-A(用户移动UI的激活)，这将在下面描述。在图29A至图29C中，将注意，假设次级装置安装至少一个移动UI。
移动UI-A根据应用启动、刷机检查等运行(a、启动应用和刷机检查)，并且诸如钥匙接收等的菜单被选择(b、选择“获得共享钥匙”)。可以在运行应用时或者在根据服务开发需要特定功能时执行应用刷机检查。
移动UI-A开始在NFC P2P模式下操作(c、开始NFC P2P操作)。
在移动UI-A的激活处理中，除了刷机检查之外的其余操作可以是可选的，因此可根据移动UI-A的提供商的实现来执行或省略所述其余操作。移动UI-A支持一个或更多个应用刷机检查机制(移动UI应支持一个或更多个应用刷机检查机制)。
在次级装置和主装置之间执行从NFC到蓝牙或Wi-Fi的切换(NFC切换到蓝牙)，其中，蓝牙或Wi-Fi的覆盖范围相对宽于NFC。这将在下面描述。
移动UI-B向移动UI-A发送用于请求从NFC切换到蓝牙的消息(例如，切换请求消息)([01]切换请求(BT))。在从移动UI-B接收到切换请求消息时，移动UI-A选择切换到蓝牙，并向移动UI-B发送指示移动UI-A选择切换到蓝牙的消息(例如，切换选择消息)([02]切换选择(BT))。也就是说，主装置成为切换请求者，并且次级装置成为切换选择者。将注意，从NFC到蓝牙的切换的更具体的参数和情况与NFC连接切换技术规范[xx]和蓝牙安全简单配对规范[xx]中描述的相同。
例如，“3cbb4363-dd09-4856-94e4-416605fa8fcb”将在切换时用作通用唯一标识符(UUID)。
根据切换请求消息和切换选择消息的交换，在移动UI-B和移动UI-A之间建立蓝牙连接([03]蓝牙连接建立)。
根据在移动UI-B和移动UI-A之间建立蓝牙连接，通过蓝牙连接在次级装置、主装置和服务提供商之间执行通信(通过蓝牙连接的通信)。
移动UI-B向服务提供商发送指示将发起接近触发钥匙共享(也就是说，指示将发起作为接近触摸的钥匙共享处理)的消息(例如，接近触发钥匙共享发起消息)([04]接近触发钥匙共享发起)。移动UI-B和服务提供商之间的接口可以以各种形式实现，并且这里将省略其详细描述。
在从移动UI-B接收到接近触发钥匙共享发起消息时，服务提供商产生随机数作为随机变量。随机数用于接收和验证次级装置的信息，这是为了在产生次级装置的信息时通过使用随机数来防止次级装置的信息的重复使用。每当钥匙共享处理开始时都新产生随机数，因此可产生针对次级装置的唯一信息。
在图29A至图29C中，假设随机数在服务提供商中产生，然而，随机数可在主装置中产生。如果随机数在主装置中产生，则在主装置中产生的随机数将是在将要描述的操作[8]中为服务提供商产生的，使得服务提供商可基于在主装置中产生的随机数来验证次级装置。
服务提供商向主装置发送用于请求将要在服务提供商处注册的次级装置的用户信息的消息(例如，用户信息请求消息)([05]用户信息请求(随机数))。这里，用户信息请求消息包括由服务提供商产生的随机数。
在从服务提供商接收到用户信息请求消息时，主装置的移动UI-B向次级装置的移动UI-A发送用于请求将要在服务提供商处注册的次级装置的信息的消息(例如，获取用户信息请求消息)([06]获取用户信息请求(随机数))。获取用户信息请求消息包括用户信息请求消息中所包括的随机数。
在从移动UI-B接收到获取用户信息请求消息时，移动UI-A执行产生将要在服务提供商处注册的次级装置的信息(例如，应用参数)的用户信息产生操作(用户信息的产生)。这里，用户信息可包括以下应用参数。
(1)ID信息
ID信息可包括MSISDN、SE ID等。此外，ID信息可包括SE发放器信息、App版本、IMEI、针对包括在次级装置中的SE的凭证、次级装置的装置型号名称、装置制造商名称、装置序列号(S/N)等。
(2)将在输出装置(例如，主装置的屏幕)上输出的信息
将在输出装置上输出的信息可包括：例如，次级装置的电话号码、次级装置的装置型号、次级装置的名称、在操作系统(OS)处注册的账户、次级装置的昵称等。
(3)公共/私有密钥对(U.Kpub、U.Kpriv)
U.Kpub表示由次级装置(即，用户装置)产生的公共密钥，U.Kpriv表示由次级装置(即，用户装置)产生的私有密钥。
(4)密钥句柄(Key Handle)
密钥句柄表示公共/私有密钥对的ID。
(5)用户签名Uinfo.Signature
用户签名Uinfo.Signature的输入参数是：ID信息、将在主装置的输出装置上输出的信息、公共密钥U.Kpub、密钥句柄和随机数值，并且是使用私有密钥U.Kpriv产生的。基于ID信息、将在主装置的输出装置上输出的信息、公共密钥U.Kpub、密钥句柄、随机数值和私有密钥U.Kpriv来产生用户签名Uinfo.Signature的方案可以以各种形式实现，并且这里将省略其详细描述。
在执行用户信息产生操作后，移动UI-A向移动UI-B发送对获取用户信息请求消息的响应消息(例如，获取用户信息响应消息)([07]获取用户信息响应(应用参数))。这里，获取用户信息响应包括由移动UI-A产生的次级装置的用户信息，即，应用参数。
在从移动UI-A接收到获取用户信息响应消息时，移动UI-B执行预确认操作(所有者预确认)。预确认操作将在下文被描述。
移动UI-B使用从移动UI-A接收的公共密钥U.Kpub来验证Uinfo.Signature(a、用户智能装置签名验证)。
如果针对Uinfo.Signature的验证成功，则移动UI-B在输出装置(例如，主装置中包括的屏幕)上输出次级装置的用户信息(b、显示可显示用户信息)。移动UI-B在输出装置上输出次级装置的用户信息的原因是用于确认次级装置的用户信息。例如，可以基于根据主装置的用户的干预的事件发生(例如，触摸确认按钮、指纹检查等)来进行该确认。在检测到输出装置上输出的用户信息被确认时(c、获得所有者同意(确认按钮、指纹检查等))，移动UI-B使用存储在主装置处的数字钥匙或者具有与数字钥匙等同的权限的钥匙来对次级装置的用户信息进行签名(使用所有者的数字钥匙对用户信息签名)。如果移动UI-B直接使用存储在SE-B处的数字钥匙，则移动UI-B使用用于数字钥匙签名的APDU。将参考图32描述用于数字钥匙签名的APDU，这里将省略其详细描述。
在执行预确认操作之后，移动UI-B向服务提供商发送对用户信息请求消息的响应消息(例如，用户信息响应消息)([08]用户信息响应(用户信息、DK签名))。用户信息响应消息包括从次级装置接收的用户信息和主装置的数字钥匙签名。在从移动UI-B接收到用户信息响应消息时，服务提供商执行用户装置验证操作和次级装置注册操作(所有者验证和用户登记)。下面将描述用户装置验证操作和次级装置注册操作。
服务提供商对主装置的数字钥匙签名执行验证操作(a、所有者数字钥匙签名验证)。也就是说，服务提供商通过对主装置的数字钥匙签名执行验证操作来确定主装置是否是拥有数字钥匙的所有者装置，或者确定主装置是否拥有适当的权限。
如果针对主装置的数字钥匙签名的验证结果成功，则服务提供商进行注册(即，存储从主装置接收并用数字钥匙进行签名的次级装置的用户信息)(b、用户信息登记)。
次级装置的用户信息包括MSISDN、U.Kpub、密钥句柄、次级装置中包括的SE的SEID(即，SE-A)等。
服务提供商产生服务提供商和次级装置将共享的共享秘密(SHS)，并通过基于次级装置的公共密钥对SHS进行加密来产生OTP(c、产生共享OTP＝enc(U.Kpub，SHS))。
SHS是用于在后续过程中验证次级装置的值。也就是说，服务提供商检查次级装置是否拥有SHS。
服务提供商产生OTP的原因是防止当服务提供商通过主装置传送相应信息(例如，数字钥匙)时，除了次级装置之外的另一装置通过对OTP解密来获得SHS。
在执行用户装置验证操作和次级装置注册操作之后，服务提供商通过用户注册结果消息向移动UI-B发送用户注册结果([09]用户注册结果(共享OTP))。如果正常注册了次级装置的用户信息，则用户注册结果消息包括共享OTP。共享OTP表示由服务提供商产生的OTP。
在从服务提供商接收到用户注册结果消息时，移动UI-B将从服务提供商接收的共享OTP传送到移动UI-A([10]推送共享OTP请求(共享OTP))。也就是说，移动UI-B通过推送共享OTP请求消息向移动UI-A传送共享OTP。在从移动UI-B接收到推送共享OTP请求消息时，移动UI-A存储共享OTP，并向移动UI-B发送对推送共享OTP请求消息的响应消息(例如，推送共享OTP响应消息)([11]推送共享OTP响应())。在发送推送共享OTP响应消息之后，移动UI-A执行SHS获取操作(获取SHS)。这里，下面将描述SHS获取操作。
移动UI-A使用作为次级装置的私有密钥的U.KPriv对共享OTP进行解码，并使用共享OTP获得SHS(用户移动UI从共享OTP和U.Kpriv计算SHS)。
尽管图29A至图29C将次级装置注册处理示出为一系列操作，但是图29A至图29C中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图30A和图30B是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置验证处理的信号流图。具体地，图30A和图30B示出在向次级装置提供DK之前检查次级装置是否拥有SHS、通过主装置确认次级装置以及与次级装置共享DK的次级装置验证处理。
在图30A和图30B中，将注意，服务提供商被示出为“车辆OEM后端”，主装置被示出为“所有者装置(DKS客户端)”，并且次级装置被示出为“用户装置”(DKS服务器)”。此外，将注意，图30A和图30B以术语“车辆OEM后端”、“所有者装置(DKS客户端)”和“用户装置(DKS服务器)”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置包括SE和移动UI，并且主装置包括移动UI和SE。在图30A和图30B中，为方便起见，包括在次级装置中的SE和移动UI将分别被称为“SE-A”和“移动UI-A”，并且包括在主装置中的SE和移动UI将分别被称为“SE-B”和“移动UI-B”。
包括在获得SHS的次级装置中的移动UI-A向服务提供商请求作为共享数字钥匙的服务的钥匙共享服务([12]由用户进行的钥匙共享触发(密钥句柄))。也就是说，移动UI-A向服务提供商发送用于请求钥匙共享服务的钥匙共享触发消息。这里，钥匙共享触发消息包括密钥句柄。
服务提供商可通过包括在钥匙共享触发消息中的密钥句柄知道哪个次级装置请求钥匙共享服务。
为了清楚地识别请求钥匙共享服务的次级装置，钥匙共享触发消息还可包括MSISDN、SE ID、IMEI等。
在从移动UI-A接收到钥匙共享触发消息时，服务提供商请求移动UI-A对用户进行验证([13]用户验证请求(质询))。例如，服务提供商可通过发送用户验证请求消息来请求用户验证，并且用户验证请求消息包括质询。
如果次级装置产生服务提供商预测的响应(即，质询响应)以向服务提供商发送质询响应，则服务提供商可确定次级装置被正常验证。在图30A和图30B中，一个质询被考虑，然而可单独地实现针对主装置的质询和针对次级装置的质询。
在图30A和图30B中，将假设使用一个质询，并且用户装置和主装置中的每个都产生对所述一个质询的质询响应。
在从服务提供商接收到用户验证请求消息时，移动UI-A计算质询响应(计算用户质询响应)。这里，由次级装置产生的质询响应将被称为用户质询响应。
基于SHS和质询来计算质询响应。在本公开的各种实施例中，质询响应也可以称为cRes。
移动UI-A可通过使用次级装置的私有密钥U.Kpriv对质询响应进行签名来产生签名。
然后，在次级装置、主装置和服务提供商之间执行主装置最终确认操作(所有者最终确认)。下面将描述主装置最终确认操作。
服务提供商触发主装置最终确认操作([14]所有者确认触发((可选的)质询))。服务提供商通过发送所有者确认触发消息来触发主装置最终确认操作。
所有者确认触发消息可包括从服务提供商发送到主装置的质询。
在操作[16]，将包括在所有者确认触发消息中的质询与将通过次级装置接收的质询进行比较，并且通过该比较操作可增强安全性。
在从服务提供商接收到所有者确认触发消息时，移动UI-B向移动UI-A请求质询值([15]获取所有者质询请求)。例如，移动UI-B可通过获取所有者质询请求消息向移动UI-A请求质询值。
在从移动UI-B接收到获取所有者质询请求消息时，移动UI-A向移动UI-B发送对获取所有者质询请求消息的响应消息(例如，获取所有者质询响应消息)([16]获取所有者质询响应(质询))。此处，获取所有者质询响应包括以下参数。
1)由移动UI-A产生的质询响应(cRes)，
2)从服务提供商接收的质询(如果在操作[13]处存在针对主装置的单独质询，则移动UI-A将针对主装置的质询而不是从服务提供商接收到的质询包括在获取所有者质询响应中)。
在从移动UI-A接收到获取所有者质询响应消息时，移动UI-B执行计算主装置的质询的所有者质询计算操作(计算所有者质询)。这里，将在下面描述所有者质询计算操作。
如果移动UI-B从服务提供商接收到质询，则移动UI-B将从服务提供商接收的质询与包括在获得所有者质询响应消息中的质询进行比较(a、[可选地]，如果从车辆OEM也给出了质询值，则比较质询)。
如果存储了次级装置的用户信息，则移动UI-B在输出装置(例如，主装置的屏幕)上输出用户信息用于最终确认(b、[可选地]，如果存在则显示可显示用户信息)。
如果用户信息被加密，则移动UI-B基于主装置的私有密钥对用户信息进行解码，并在输出装置(例如，屏幕)上输出解码后的用户信息。
如果屏幕上输出的用户信息(即，屏幕上显示的用户信息)与预确认操作中的用户信息不同，则预期发生诸如中间人攻击等的安全攻击，因此可以阻止针对次级装置的共享钥匙提供。
在检测到最终确认时，移动UI-B使用存储在主装置的数字钥匙或拥有等同于数字钥匙的权限的钥匙来最终确认次级装置的用户信息。
这里，最终确认被产生为主装置的质询响应(oRes)的形式，并通过次级装置被传送到服务提供商，并且服务提供商对质询响应(oRes)进行验证。
使用质询、cRes和数字钥匙(或拥有等同于数字钥匙的权限的钥匙)产生oRes(即，主装置的质询响应)。
在移动UI-B直接使用存储在SE-B处的数字钥匙的情况下，移动UI-B通过使用用于数字钥匙签名的APDU对质询和用户信息进行签名来产生主装置的质询响应(oRes)(签名(质询，数字钥匙，cRes))。将参照图32描述数字钥匙签名，这里将省略其详细描述。
可以使用散列函数(hash function)等而不使用签名来产生质询响应(oRes)。此时，通过考虑将质询、用户信息和数字钥匙全部作为散列函数的输入参数(Hash(质询，数字钥匙，cRes))来产生所有者质询结果(所有者质询结果)。
移动UI-B向移动UI-A发送产生的所有者质询结果([17]设置质询结果请求(所有者质询结果))。例如，移动UI-B通过设置质询结果请求消息向移动UI-A发送产生的所有者质询结果。
在从移动UI-B接收到设置质询结果请求消息时，移动UI-A向移动UI-B发送对设置质询结果请求消息的响应消息(例如，设置质询结果响应消息)([18]设置质询结果响应())。设置质询结果响应消息包括移动UI-A直接产生的质询响应(cRes)和从移动UI-B接收的质询响应(oRes)。如果质询响应(oRes)未存储在次级装置，则设置质询结果响应消息不是质询响应(oRes)。
移动UI-A设置对通过设置质询结果请求消息接收的所有者质询结果的质询响应(oRes)(oRes＝所有者质询结果)。
如上所述，在执行主装置最终确认操作之后，移动UI-A发送对用户验证请求消息的响应消息(例如，用户验证响应消息)([19]用户验证响应(cRes，[可选的]oRes))。这里，用户验证响应消息包括由移动UI-A产生的质询响应(cRes)和从移动UI-B接收的质询响应(oRes)。如果不存在质询响应(oRes)，则用户验证响应可仅包括由移动UI-A产生的质询响应(cRes)。
在从移动UI-A接收到用户验证响应消息时，服务提供商执行对次级装置的验证操作(用户验证)。下面将描述对次级装置的验证操作。
在从移动UI-A接收到用户验证响应消息时，服务提供商对包括在用户验证响应消息中的质询响应(即，cRes和oRes)执行验证操作(a、cRes验证；b、[可选的]oRes验证)。如果针对cRes和oRes的验证结果成功，则服务提供商向次级装置提供数字钥匙。也就是说，在服务提供商和次级装置之间执行数字钥匙提供处理([20]根据CCC一般处理的数字钥匙提供)。
服务提供商可通过将指示针对次级装置的数字钥匙提供结果的消息发送到主装置来使主装置识别出数字钥匙被提供给次级装置([21]客户端数字钥匙提供结果的通知)。
尽管图30A和图30B示出根据本公开的另一实施例的在通信系统中提供数字钥匙的处理中包括的次级装置验证处理的示例，但是可以对图30A和图30B进行各种改变。例如，尽管被示出为一系列操作，但是图30A和图30B中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图31示出根据本公开的实施例的通信系统中的DK共享服务的协议栈的结构。
参照图31，基带层、链路管理协议(LMP)层、以及逻辑链路控制和适配协议(L2CAP)层是蓝牙协议的物理和数据链路层。射频通信(RFCOMM)层是蓝牙串行端口仿真实体。服务发现协议(SDP)层是蓝牙服务发现协议层。
此外，DK共享服务可被定义为客户端和服务器之间使用DK共享服务UUID打开的潜在对象交换(OBEX)会话。
DKSC发起将对象推拉到DKSS的操作以及从DKSS推拉对象的操作。例如，主装置可充当DKSC。
DKSS是提供对象交换服务器的目标蓝牙装置。例如，次级装置可充当DKSS。
DK共享服务UUID(即，用于DK共享服务的UUID)可以是“3cbb4363-dd09-4856-94e4-416605fa8fcb”。
DK共享服务UUID可考虑从蓝牙特殊兴趣组(BT SIG)获得16比特唯一UUID。
下面将描述蓝牙安全。
两个装置可使用如通用访问规范中描述的认证过程来产生安全连接。DK共享服务可分配以下蓝牙安全特征。这两个装置应使用通用访问规范中描述的认证过程创建安全连接。DK共享服务要求使用多种蓝牙安全特征。
(1)绑定
在建立DK服务连接之前，可绑定DKSC和DKSS。如果DKSC和DKSS二者都支持安全模式4，则可使用安全模式4。可应用使用带外(NFC)模型的安全简单配对。
(2)加密
可使用蓝牙加密对DKSC和DKSS之间的链路进行加密。
(3)链路密钥
组合密钥可用于DK共享服务连接。
(4)加密密钥长度
加密密钥的长度至少为64比特。为了增强安全性，可使用最大长度的加密密钥，并且最大长度遵循给定的区域规则。
DK共享服务函数可如下表12中所示被表示。
表12
Figure GDA0002138630260000601
Figure GDA0002138630260000611
在表12中，与用户注册有关的函数包括获取用户信息函数和推送共享OPT函数，并且与用户验证有关的函数包括获取所有者质询函数和设置质询结果函数。
获取用户信息函数可如下表13中所示被表示。
表13
Figure GDA0002138630260000612
在表13中，在BT通用对象交换规范(GOEP)中描述了GET，并且根据是否设置了最终比特来确定GET的值。在获取用户信息函数中，响应可如下表14中所示被形成。
表14
Figure GDA0002138630260000613
Figure GDA0002138630260000621
下面将描述表13和表14中的字段/头。
(1)连接ID
连接ID头应被用于指示在连接建立期间接收的连接ID，以便向请求的接收者发信号通知请求属于哪个OBEX连接。
(2)类型
Type头应被用于指示将发送的对象的类型：
<x-bt/DKS-用户信息>
(3)应用参数
-随机数
该头应由DKSC使用以向DKSS发送从服务提供商(例如，车辆OEM服务器)接收的随机数值。
-MSISDN/SE标识符/IMEI/装置序列号
这些头用于识别将共享DK的用户。MSISDN和SE标识符参数应由DKSS发送。如果需要，可包括其他(IMEI、装置序列号)。
-可显示用户信息
该头应包含与将在所有者智能装置显示器的屏幕上示出的用户信息有关的文本。
-用户公共密钥
该包头应包含由次级装置(例如，用户智能装置)新创建的用于当前DK共享服务会话的公共密钥。当DKSS被请求通过获取用户信息函数提供用户信息时，用户智能装置应创建公共密钥和私有密钥的密钥对。
-用户密钥句柄
该头应包含密钥对的标识。该句柄由DKSS和车辆OEM服务器使用以识别将用于产生和计算共享OTP的密钥。
-用户签名
该头应包含结果签名。DKSS产生包括用户密钥句柄值、用户公共密钥值、可显示用户信息值、MSISDN、SE标识符和随机数的签名。如果IMEI和/或装置序列号存在于获取用户信息响应中，则它们的值也应组成签名。
推送共享OTP函数使DKSC能够发送由服务提供商(例如，车辆OEM服务器)产生的共享OTP。
下面将描述推送共享OTP函数的公共字段和头，并且应用服务可包括附加头。
可如下面的表15所示形成推送共享OTP函数中的请求。
表15
Figure GDA0002138630260000631
可如下表16所示形成推送共享OTP函数中的响应。
表16
Figure GDA0002138630260000632
下面将描述表15和表16中的字段/头。
(1)连接ID
连接ID头应被用于指示在连接建立期间接收的连接ID，以便向请求的接收者发信号通知该请求属于哪个OBEX连接。
(2)类型
类型头应被用于指示将被发送的对象的类型：
<x-bt/DKS-共享OTP>
(3)应用参数
-共享OTP
该头应包含由DKSC从车辆OEM服务器接收的共享OTP。
获取所有者质询函数用于DKSC从DKSS获得所有者质询。所有者质询由服务提供商(例如，车辆OEM服务器)产生，并且从次级装置(例如，用户装置)被接收。
下面将描述获取所有者质询函数的公共字段和头，并且应用服务可以包括附加的头。
在获取所有者质询函数中，可形成如下表17中所示的请求。
表17
Figure GDA0002138630260000641
在获取所有者质询函数中，可如下表18中所示形成响应。
表18
Figure GDA0002138630260000642
Figure GDA0002138630260000651
下面将描述表17和表18中的字段/头。
(1)连接ID
连接ID头应被用于指示在连接建立期间接收的连接ID，以便向请求的接收者发信号通知该请求属于哪个OBEX连接。
(2)类型
类型头应被用于指示将被发送的对象的类型：
<x-bt/DKS-所有者质询>
(3)应用参数
-质询
该头应包括由DKSS从车辆OEM服务器接收的质询。
-可显示用户信息
可显示用户信息头应包含与将在所有者智能装置显示器的屏幕上示出的用户信息有关的文本。
设置质询结果函数使得DKSC能够向DKSS发送所有者质询的计算结果。
下面将描述设置质询结果函数的公共字段和头，并且应用服务可包括附加的头。
在设置质询结果函数中，可如表19中所示形成请求。
表19
Figure GDA0002138630260000652
在设置质询结果函数中，可如表20中所示形成响应。
表20
Figure GDA0002138630260000653
下面将描述表19和表20中的字段/头。
(1)连接ID
连接ID头应被用于指示在连接建立期间接收的连接ID，以便向请求的接收者发信号通知该请求属于哪个OBEX连接。
(2)类型
类型头应被用于指示将被发送的对象的类型：
<x-bt/DKS-所有者质询结果>
(3)应用参数
-所有者质询结果
该头应包含使用存储在所有者智能装置中的DK计算出的所有者质询响应的结果。
可如表21所示形成应用参数头中使用的标签ID。
表21
Figure GDA0002138630260000661
图32是示出根据本公开的实施例的通信系统中的主装置的操作处理的信号流图。具体地，图32示出使用主装置的DK产生数字签名的处理。
可通过对ISO 7816-8中描述的执行安全操作命令中的COMPUTE DIGITALSIGNATURE操作进行修改来实现根据本公开的实施例提出的DK产生处理。
ISO 7816-8使用ISO 7816-4中描述的APDU，所述APDU是用于向SE发送命令的通用数据形式，并且所述APDU的格式可如下表22中所示被表示。
表22
Figure GDA0002138630260000671
表22的第一部分指示命令，表22的第二部分指示对命令的响应。所述命令包括：命令头、Lc、数据字段和Le字段。命令头字段将CLA指示为类型字节代码，并指示发送的命令是安全消息还是遵循在特定协会中定义的格式的消息。在命令头字段中，INS表示指令字段，INS指定与相应消息相应的命令(例如，存储、获取、执行安全操作(PerformSecurityOperation)等)。P1-P2的含义可基于INS改变。在本公开中，当应用INS＝执行安全操作时，P1和P2指示以下内容。
P1＝定义将执行的安全操作(例如：数字签名(P1＝9E))。
P2＝含义根据P1被改变，并指定基于INS和P1确定的命令。在本公开中，P2用于在以下情况下识别数字签名被执行：1)当次级装置在服务提供商处注册时(P2＝'xx')，或2)用于在次级装置和服务提供商之间执行认证时执行最终确认(P2＝'yy')。
表22的第二部分指示对命令的响应APDU，并且响应APDU被划分为数据字段和响应尾部字段。根据响应的类别，数据字段可存在或不存在。响应尾部字段包括两个状态字节(SW)值。状态字节表示命令APDU的结果。
可使用ISO 7816-4中定义的状态字节，或者可以针对每个标准协会新定义状态字节。
主装置(即，所有者装置)包括移动UI和SE，并且SE命令在移动UI和SE之间运行。
参照图32，COMPUTE DIGITAL SIGNATURE操作发起数字签名的计算。也就是说，移动UI向SE发送用于请求执行数字签名计算的消息(例如，执行安全操作-计算数字签名ADPU([01][APDU]执行安全操作-计算数字签名))。
可通过数字签名算法或通过散列算法和数字签名算法的组合来执行数字签名的计算。
为了计算数字签名，在签名处理中将要被签名或集成的数据被包括在命令数据字段中，并且数字签名被指定为P2中的标签“XX”。
例如，可如下表23中所示来表示在数字签名计算操作中使用的代码。
表23
Figure GDA0002138630260000681
尽管表23中每个代码的存在被表示为“强制”，但根据情况，每个代码的存在可以是“强制”、“有条件”或“可选”。
在表23中，数据字段可如下表24中所示被表示。
Figure GDA0002138630260000691
在表24中，用户安全标识符、用户证书和用户MSISDN是在预确认操作中使用的数据格式，并且用户质询响应和(通过用户从车辆OEM后端接收的)质询是在后确认操作中使用的数据格式。
此外，可根据情况改变表24中的每种数据格式的存在。例如，在表24中，针对P2＝xx，用户安全标识符的存在被设置为强制或有条件，然而，根据情况，用户安全标识符的存在被设置为可选。在表24中，针对P2＝xx，用户MSISDN的存在被设置为有条件，然而，根据情况，用户MSISDN的存在可被设置为强制或可选。
数据字段被定义为类型-长度-值(TLV)形式，并且类型被表示为“xx”或“yy”，然而，这些值可被替换为在标准协会中定义的值。
在从移动UI接收到执行安全性操作-计算数字签名APDU时，在步骤3202中，SE发送如下表25中所示的包括数字签名的执行安全性操作响应APDU。这里，错误代码“未找到DK对象”被添加到状态字节。所述错误代码用于通知在SE中不存在将被用于签名的DK或等同于DK的钥匙。
表25
Figure GDA0002138630260000692
Figure GDA0002138630260000701
图33A和图33B是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图。具体地，图33A和图33B示出次级装置和次级装置的用户信息如何在服务提供商处被注册。
在图33A和图33B中，将注意，服务提供商被示出为“车辆OEM后端”，主装置被示出为“所有者装置”，并且次级装置被示出为“客户端装置”。此外，将注意，图33A和图33B以术语“车辆OEM后端”、“所有者装置”和“客户端装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置包括SE和移动UI，并且主装置包括移动UI和SE。在图33A和图33B中，为方便起见，包括在次级装置中的SE和移动UI将分别被称为“SE-A”和“移动UI-A”，并且包括在主装置中的SE和移动UI将分别被称为“SE-B”和“移动UI-B”。移动UI-A和移动UI-B可分别访问SE-A和SE-B。也就是说，移动UI表示能够与其他装置进行P2P通信并可访问SE的实体。
首先，激活移动UI-B(所有者移动UI的激活)，这将在下面描述。
移动UI-B根据应用启动、刷机检查等运行(a、启动应用和刷机检查)，并且诸如钥匙传送、钥匙共享等的菜单被选择(b、选择“共享我的钥匙”)。可以在运行应用时或者在根据服务开发需要特定功能时执行应用刷机检查。
如果根据移动UI-B的提供商或服务提供商的服务策略需要的话，可执行用户认证处理(c、用户认证)，并可基于生物特征、已提前在主装置上注册的PIN等执行用户认证处理。移动UI-B开始在NFC P2P模式下操作(d、开始NFC P2P操作)。
在移动UI-B的激活处理中，除了刷机检查之外的其余操作可以是可选的，因此可根据移动UI-B的提供商的实现来执行或省略所述其余操作。移动UI-B支持一个或更多个应用刷机检查机制(移动UI应支持一个或更多个应用刷机检查机制)。
此外，激活移动UI-A(用户移动UI的激活)，这将在下面描述。在图33A和图33B，将注意，假设次级装置安装至少一个移动UI。
移动UI-A根据应用启动、刷机检查等运行(a、启动应用和刷机检查)，并且诸如钥匙接收等的菜单被选择(b、选择“获得共享钥匙”)。可以在运行应用时或者在根据服务开发需要特定功能时执行应用刷机检查。
移动UI-A开始在NFC P2P模式下操作(c、开始NFC P2P操作)。
在移动UI-A的激活处理中，除了刷机检查之外的其余操作可以是可选的，因此可根据移动UI-A的提供商的实现来执行或省略所述其余操作。移动UI-A支持一个或更多个应用刷机检查机制(移动UI应支持一个或更多个应用刷机检查机制)。
移动UI-B向服务提供商发送指示将发起接近触发钥匙共享(也就是说，指示将发起作为接近触摸的钥匙共享处理)的消息(例如，接近触发钥匙共享发起消息)([01]接近触发钥匙共享发起)。移动UI-B和服务提供商之间的接口可以以各种形式实现，并且这里将省略其详细描述。
在从移动UI-B接收到接近触发钥匙共享发起消息时，服务提供商产生随机数作为随机变量。随机数用于接收和验证次级装置的信息，这用于在产生次级装置的信息时通过使用随机数来防止次级装置的信息的重复使用。每当钥匙共享处理开始时都新产生随机数，因此可产生用于次级装置的唯一信息。
服务提供商向主装置发送用于请求将在服务提供商处注册的次级装置的用户信息的消息(例如，客户端信息请求消息)([02]客户端信息请求(随机数＝n))。这里，客户端信息请求消息包括由服务提供商产生的随机数。在图33A和图33B中，将假设由服务提供商产生的随机数是“n”(随机数＝n)。
在从服务提供商接收到客户信息请求消息时，主装置的移动UI-B向次级装置的移动UI-A发送用于请求将在服务提供商处注册的用户信息的消息(例如，客户端信息请求消息)([03]客户端信息请求(n))。在操作[03]发送的客户端信息请求消息包括操作[02]发送的客户端信息请求消息中所包括的随机数。
在从移动UI-B接收到客户端信息请求消息时，移动UI-A执行产生将在服务提供商处注册的用户信息的用户信息产生操作([用户信息的产生])。下面将描述用户信息产生操作。
移动UI-A产生公共/私有密钥对(C.Kpub、C.Kpriv)，产生句柄h作为公共/私有密钥对(C.Kpub、C.Kpriv)的ID，并产生用户信息。用户信息包括以下参数。
(1)SE ID和MSISDN
(2)如果需要，用户信息还可包括SE发放器信息、App版本、IMEI、次级装置SE的凭证(即，SE-A)、次级装置型号名称、次级装置制造商名称、次级装置S/N等。
包括在用户信息中的SE ID、IMEI等用于识别次级装置，并且MSISDN用于识别次级装置的用户。
移动UI-A通过使用私有密钥C.Kpriv对用户信息、句柄h、公共密钥C.Kpub和随机数值进行签名来产生用户信息签名(Cinfo.Signature)。Cinfo.Signature表示由客户端装置(即，次级装置)产生的用户信息签名。
在执行用户信息产生操作之后，移动UI-A向移动UI-B发送对客户端信息请求消息的响应消息(例如，客户端信息响应消息)([04]客户端信息响应(C Info))。客户端信息响应消息包括移动UI-A产生的用户信息、次级装置的公共密钥C.Kpub、句柄h和Cinfo.Signature。
如果次级装置和主装置之间的连接基于NFC方案，则可执行从NFC方案到另一方案(例如，Wi-Fi、蓝牙等)的切换，以用于改善用户体验(UX)。这将在下面描述。
在图33A和图33B中，将假设执行从NFC到其他连接的切换。在这种情况下，移动UI-B向移动UI-A发送用于请求从NFC切换到其他连接的消息(例如，切换请求消息)([01]切换请求)。在从移动UI-B接收到切换请求消息时，移动UI-A选择切换到其他连接，并向移动UI-B发送指示移动UI-A选择切换到其他连接的消息(例如，切换选择消息)([02]切换选择)。也就是说，主装置成为切换请求者，并且次级装置成为切换选择器。将注意，用于从NFC到其他连接的切换的更具体的参数和情况与NFC连接切换技术规范[xx]中描述的相同。
根据切换请求消息和切换选择消息的交换，在移动UI-B和移动UI-A之间建立基于其他连接的连接([07]建立切换连接(WiFi、BT等))。
移动UI-B执行预确认操作(所有者预确认)。将在下面描述预确认操作。
移动UI-B使用从移动UI-A接收的公共密钥C.Kpub来对Cinfo.Signature进行验证(a、检查签名)。
如果针对对Cinfo.Signature的验证成功，则移动UI-B在输出装置(例如，包括在主装置中的屏幕)上输出次级装置的用户信息(b、用户信息在所有者的显示器中被示出)。移动UI-B在输出装置上输出次级装置的用户信息的原因是用于确认次级装置的用户信息。例如，可基于根据主装置的用户的干预的事件发生(例如，触摸确认按钮、指纹检查等)进行该确认。在检测到输出装置上输出的用户信息被确认时(c、所有者确认用户信息)，移动UI-B使用存储在主装置处的数字钥匙或具有与数字钥匙等同权限的钥匙来对次级装置的用户信息进行签名(使用所有者的数字钥匙对客户端信息进行签名)。如果移动UI-B直接使用存储在SE-B处的数字钥匙，则移动UI-B使用用于数字钥匙签名的APDU。已经参考图32描述了用于数字钥匙签名的APDU，这里将省略对其的详细描述。
在执行预确认操作之后，移动UI-B向服务提供商发送对客户端信息请求消息的响应消息(例如，客户端信息响应消息)([08]客户端信息响应(C Info、DK签名)。客户端信息响应消息包括从次级装置接收的客户端信息和主装置的数字钥匙签名。
在从移动UI-B接收到客户端信息响应消息时，服务提供商执行用户装置验证操作和次级装置注册操作(所有者验证和用户登记)。下面将描述用户装置验证操作和次级装置注册操作。
服务提供商对主装置的数字钥匙签名执行验证操作(a、数字钥匙签名验证)。也就是说，服务提供商通过对主装置的数字钥匙签名执行验证操作来确定主装置是否是拥有数字钥匙的所有者装置，或者主装置是否拥有适当的权限。
如果针对主装置的数字钥匙签名的验证结果成功，则服务提供商进行注册(即，存储从主装置接收并用数字钥匙进行签名的次级装置的用户信息)(b、C.Infor、句柄、C.Kpub登记)。
次级装置的用户信息包括MSISDN、C.Kpub、句柄h、次级装置中包括的SE的SE ID(即，SE-A)等。
服务提供商产生服务提供商和次级装置将共享的共享秘密(SHS)，并通过基于次级装置的公共密钥对SHS进行加密来产生OTP(c、创建OTP＝enc(C.Kpub，SHS)。
SHS是用于在后续过程中验证次级装置的值。也就是说，服务提供商检查次级装置是否拥有SHS。
服务提供商产生OTP的原因是防止当服务提供商通过主装置传送相应信息(例如，数字钥匙)时，除了次级装置之外的另一装置通过对OTP解密来获得SHS。
在执行用户装置验证操作和次级装置注册操作之后，服务提供商通过用户注册结果消息向移动UI-B发送客户端注册结果([09]客户端注册结果(OTP))。如果正常注册了次级装置的用户信息，则用户注册结果消息包括OTP。OTP表示由服务提供商产生的OTP。
在从服务提供商接收到用户注册结果消息时，移动UI-B将从服务提供商接收的OTP传送到移动UI-A([10]客户端注册结果(OTP))。也就是说，移动UI-B通过客户端注册结果消息向移动UI-A传送OTP。
移动UI-A执行SHS获取操作(SHS的获取)。这里，下面将描述SHS获取操作。
移动UI-A使用作为次级装置的私有密钥的C.KPriv对OTP进行解码，并使用OTP获得SHS(客户端移动UI从OTP和C.Kpriv计算SHS)。
尽管图33A和图33B将次级装置注册处理示出为一系列操作，但是图33A和图33B中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图34A和图34B是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图。具体地，图34A和图34B示出次级装置和次级装置的用户信息如何在服务提供商处被注册。
在图34A和图34B中，将注意，服务提供商被示出为“车辆OEM后端”，主装置被示出为“所有者装置”，并且次级装置被示出为“客户端装置”。此外，将注意，图34A和图34B以术语“车辆OEM后端”、“所有者装置”和“客户端装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置包括SE和移动UI，并且主装置包括移动UI和SE。在图34A和图34B中，为方便起见，包括在次级装置中的SE和移动UI将分别被称为“SE-A”和“移动UI-A”，并且包括在主装置中的SE和移动UI将分别被称为“SE-B”和“移动UI-B”。移动UI-A和移动UI-B可分别访问SE-A和SE-B。也就是说，移动UI表示能够与其他装置进行P2P通信并可访问SE的实体。
将注意，图34A和图34B中的次级装置注册处理类似于图33A和图33B中的次级装置注册处理，然而，图34A和图34B中的次级装置注册处理在以下方面中与图33A和图33B中的次级装置注册处理不同。
首先，主装置在获得次级装置的用户信息之前不与服务提供商执行通信。
其次，主装置先前未执行与服务提供商的通信，主装置中包括的移动UI-B产生随机数值以将该随机数值传送到包括在次级装置中的移动UI-A，并且当向服务提供商传送次级装置的用户信息时，将随机数值连同次级装置的用户信息一起传送到服务提供商，从而服务提供商可验证所述用户信息。
此外，将注意，图34A和图34B中的操作[06]至操作[08]类似于图33A和图33B中的操作[08]至操作[10]。然而，只有Req-Res机制中的函数的名称是不同的。
尽管图34A和图34B将次级装置注册处理示出为一系列操作，但是图34A和图34B中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图35示出根据本公开的实施例的在通信系统中提供DK的处理。具体地，图35示出主装置首先请求与次级装置进行钥匙共享，并且服务提供商对主装置提供的共享令牌进行验证的DK提供处理。
参照图35，将注意，服务提供商被示出为“OEM服务器”，主装置被示出为“所有者实体”，并且次级装置被示出为“客户端终端”。此外，将注意，图35以术语“OEM服务器”、“所有者实体”和“客户端终端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图35中的数字钥匙提供处理是在主装置首先请求与次级装置进行钥匙共享并且服务提供商验证主装置提供的共享令牌的情况下的数字钥匙提供处理。
如果主装置向服务提供商请求钥匙共享(1、钥匙共享请求)，则服务提供商提供随机数(2、提供随机数)。服务提供商向主装置传送提供的随机数(3、传送随机数)，主装置基于随机数和数字钥匙产生共享令牌(4、基于随机数和数字钥匙(或已经在主装置和服务提供商之间共享的SHS)产生共享令牌)。
主装置与次级装置建立NFC连接(5、NFC连接)，并向次级装置发送共享令牌(6、传送共享令牌)。在从主装置接收到共享令牌时，次级装置向服务提供商请求服务，也就是说，次级装置请求数字钥匙提供(7、请求服务(例如，数字钥匙提供))，以便在次级装置和服务提供商之间执行针对共享令牌的验证操作(8、验证共享令牌)。如果针对共享令牌的验证结果成功，则服务提供商向次级装置提供服务(9、提供服务)。也就是说，如果针对共享令牌的验证结果成功，则服务提供商向次级装置提供数字钥匙。
图36是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图36，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图36以术语“OEM”、“所有者智能装置”和“客户端智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
主装置向服务提供商发送用于请求钥匙共享服务的消息(1、钥匙共享请求(所有者ID)、(可选的)访问属性)。用于请求钥匙共享服务的消息可包括诸如主装置的标识符的ID(即，所有者ID)等。用于请求钥匙共享服务的消息可以可选地包括诸如访问属性等的信息。
这里，访问属性可包括钥匙寿命、自动驾驶距离、与可以驾驶车辆的区域相关的信息(例如，地理围栏(例如，指示可以在特定区域驾驶车辆的信息))、车辆属性(例如，最大速度等)以及车辆使用权限(例如，车门打开、后备箱打开、启动车辆等)。
服务提供商向主装置发送对钥匙共享请求的响应、随机数和服务ID(2、钥匙共享响应(随机数、服务ID))。随机数可以例如用于防止在主装置中产生令牌的重复使用。
当次级装置请求钥匙提供(即，“7”操作)时，服务ID可用于在服务提供商、主装置和次级装置之间匹配服务同步。
主装置使用存储在主装置处的数字钥匙或具有与数字钥匙等同权限的钥匙来产生共享令牌。可基于数字钥匙或具有与数字钥匙等同权限的钥匙并基于从服务提供商提供的随机数来产生共享令牌(3、执行安全操作APDU：令牌产生操作；4、Shr.Token＝Hash(输出数据，DK.Sharing)；5、rsp.(Shr.Token)；由OEM计算Shr.Token＝Hash(输入数据，DK.Sharing))。
然后，在次级装置和主装置之间建立基于短程通信方案(诸如NFC、BT等)的通信环境。在图36中，将假设在次级装置和主装置之间建立基于NFC方案的通信环境。也就是说，在图36中，将假设在次级装置和主装置之间建立NFC连接(NFC连接建立)。因此，将假设在次级装置和主装置之间产生安全信道。
次级装置向主装置传送共享令牌和服务ID(6、传送ShrToken和服务ID)。
次级装置向服务提供商请求数字钥匙共享(7、钥匙共享请求(服务ID))。
服务提供商可通过服务ID识别出次级装置已连接到哪个主装置等。
服务提供商发送验证请求以及质询(8、Shr.Token验证请求(质询))。
服务提供商请求验证的原因是检查次级装置是否具有由主装置产生的共享令牌。
次级装置产生质询响应，并向服务提供商发送质询响应(9、计算质询响应＝f(ShrToken，质询)；10.质询响应)。
可基于(由主装置提供的)共享令牌和(由服务提供商提供的)质询来产生质询响应。
服务提供商对从次级装置接收的质询响应进行验证(11、由OEM计算质询响应＝f(ShrToken_by OEM，质询)；12、由OEM通过与质询响应进行比较来对质询响应进行验证)。
服务提供商知道随机数的值和质询的值，并可通过所有者ID知道主装置使用哪个数字钥匙。
因此，服务提供商基于所述值计算共享令牌(随机数+数字钥匙)，并计算质询响应(共享令牌+质询)。
服务提供商基于从次级装置传送的质询响应与由服务提供商计算出的质询响应是否相同来对次级装置进行验证。
例如，将假设在服务提供商、主装置和次级装置之间同步或预先确定共享令牌计算函数和质询响应计算函数的使用。
如果针对次级装置的验证结果成功，则服务提供商向次级装置提供数字钥匙(13、提供服务(钥匙提供等)，(可选地)，如果存在访问属性，则提供反映了访问属性的服务)。
这里，如果访问属性在“1”操作处被设置，则服务提供商提供反映了与所设置的访问属性相应的特征的数字钥匙。
同时，数字钥匙和访问属性可被存储在不同装置处或装置的不同区域处。例如，数字钥匙可被存储在SE处，并且访问属性可被存储在单独装置或区域(诸如TEE等)处。
尽管图36将信号发送/接收操作示出为一系列操作，但是图36中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图37示出根据本公开的实施例的在通信系统中提供DK的处理。具体地，图37示出下述DK提供处理：在该处理中，次级装置访问服务提供商，向服务提供商请求服务，并从服务提供商获得服务访问信息，并且主装置基于由次级装置获得的服务访问信息访问服务提供商，并执行用于认证的确认操作和主要信息传送。
参照图37，将注意，服务提供商被示出为“服务提供商”，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图37以术语“服务提供商”、“所有者”和“客户端”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
将注意，图37中的数字钥匙提供处理是在以下情况下的数字钥匙提供处理：次级装置访问服务提供商，向服务提供商请求服务，并从服务提供商获得服务访问信息，并且主装置基于由次级装置获得的服务访问信息来访问服务提供商，并执行用于认证的确认操作和主要信息传送。
次级装置向服务提供商请求服务(1、请求服务)，因此服务访问信息在服务提供商和次级装置之间被传送(2、传送服务访问信息(网络(N/W)信息、统一资源定位符(URL)、服务ID等))。这里，服务访问信息可包括例如N/W信息、URL信息、服务ID等。
次级装置向主装置发送服务访问信息和次级装置的信息(3、服务访问信息重传+客户端信息)。在从次级装置接收到服务访问信息和次级装置的信息时，主装置访问服务提供商(4、访问服务器)，并在服务提供商和主装置之间进行所有者认证过程(即，主装置认证过程)(5、认证所有者)。如果主装置认证过程成功，则主装置向服务提供商请求服务(请求服务(钥匙提供、主要信息代替传送等)，并且(可选地)，访问属性被包括)。这里，服务请求可以是例如请求为次级装置提供数字钥匙的服务请求。
在从主装置接收到服务请求时，服务提供商向次级装置提供服务(7、提供服务(提供钥匙或传送从所有者接收的信息)。
图38是示出根据本公开的实施例的在通信系统中提供DK的处理的信号流图。
参照图38，将注意，服务提供商被示出为“服务提供商”，主装置被示出为“被授权的实体(所有者)”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图38以术语“服务提供商”、“被授权的实体(所有者)”和“客户端智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置向服务提供商请求服务(1、服务请求(钥匙共享、安全共享等))。这里，将在下面描述服务的种类。
服务的种类可包括以下服务：诸如，接收其他装置的主要信息的服务(诸如钥匙共享)等，例如，在本公开的各种实施例中的接收用于共享钥匙的主要信息的服务；在主装置的许可下使用次级装置没有直接订阅的服务的服务；以及想要通过服务提供商安全地接收主装置的主要信息(例如，凭证、ID、密码(PW)等)的服务。
服务提供商向次级装置传送安全服务访问信息(2、传送服务访问信息(N/W访问信息、服务器URL、服务ID等))。这里，服务访问信息可包括暂时可用的网络访问信息、服务相关的服务URL、服务ID等。
如果必要，服务提供商可预先执行进行检查的操作(诸如是否已在次级装置上进行刷机、应用是否是可信应用等)。在主装置和次级装置之间建立了NFC连接的状态下(NFC连接建立)，次级装置向主装置请求服务许可(例如，钥匙共享、信息共享、登录许可等)(3.信息共享请求(服务访问信息、客户端ID))。次级装置可传送从服务提供商接收的服务访问信息。也就是说，次级装置可发送包括服务访问信息和次级装置的ID(即，客户端ID)的服务许可请求。
主装置基于从次级装置接收的服务访问信息来访问服务提供商(4、基于服务访问信息的服务器访问)。
在主装置和服务提供商之间执行用于认证主装置的过程。也就是说，服务提供商对主装置进行验证以验证服务提供商是否可许可服务(5、所有者认证(帐户认证、数字钥匙认证等)。服务提供商可通过检查数字钥匙是否存储在主装置处来对主装置进行验证。这在假设服务提供商和主装置共享数字钥匙的情况下是可行的。
可选地，服务提供商可通过检查主装置是否是已经订阅服务提供商的服务的用户或是在服务提供商的服务处注册的用户来对主装置进行验证。这在假设信息被传送并且服务被许可的情况下是可能的。
服务提供商和主装置可另外地执行清楚要求主装置的用户的同意的操作，诸如由用户输入确认按钮的操作、认证指纹的操作等。
如果存在将与次级装置共享的信息，则主装置向服务提供商传送所述信息(6、传送将被共享的安全信息(例如，访问属性或安全信息))。
服务提供商提供次级装置请求的信息和服务，并且主装置向次级装置确认(7、传送安全信息)。
情况1：如果主要信息(诸如凭证等)存储在主装置处，则主装置将主要信息上传到服务提供商。
情况2：在数字钥匙共享的情况下，主装置向服务提供商传送钥匙ID、钥匙属性等，服务提供商向次级装置提供与标准相应的数字钥匙。
情况3：如果服务提供商仅需要提供特定服务(例如，音乐收听服务等)，则可省略操作“6”，并且在如操作“5”所述的针对主装置的认证之后立即提供服务。
尽管图38示出根据图37中的数字钥匙提供处理的在次级装置、主装置和服务提供商之间的信号发送/接收操作，但是可对图38进行各种改变。例如，尽管被示出为一系列操作，但是图38中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
属性协议(ATT)是支持读取和写入属性的协议。ATT表示用于发送和接收属性的协议。GATT是指定如何配置和定义将被发送的属性的标准。可使用属性来定义随机数、公共密钥等，并且可通过发送和接收特定属性来实现服务。根据本公开的实施例，将在CCC中定义的属性的逻辑格式可如图39中所示被表示。
图39示出根据本公开的实施例的通信系统中的属性的格式。
参照图39，属性句柄(Attribute Handle)表示指示特定属性的索引，并例如以2个八位字节长度来实现。属性类型(Attribute Type)表示UUID，并描述特定属性值定义的内容。
属性值是属性类型+属性句柄，并指示可被识别的属性的实际值。例如，如果属性句柄＝0并且属性类型＝随机数，则属性值＝1234。
图40示出根据本公开的实施例的通信系统中的GATT配置文件堆栈的结构。
参照图40，根据本公开的实施例的GATT配置文件堆栈基于在如图40右侧所示的蓝牙低功耗(BLE)。
图41A至图41C是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图。具体地，图41A至图41C示出次级装置和次级装置的信息如何在服务提供商处被注册。
在图41A至图41C中，将注意，服务提供商被示出为“汽车OEM后端”，主装置被示出为“所有者装置(DKS客户端)”，并且次级装置被示出为“用户装置(DKS服务器)”。此外，将注意，图41A至图41C以术语“汽车OEM后端”、“所有者装置(DKS客户端)”和“用户装置(DKS服务器)”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置包括SE和移动UI，并且主装置包括移动UI和SE。在图41A至图41C中，为方便起见，包括在次级装置中的SE和移动UI将分别被称为“SE-A”和“移动UI-A”，并且包括在主装置中的SE和移动UI将分别被称为“SE-B”和“移动UI-B”。移动UI-A和移动UI-B中的每个都能够与其他装置进行P2P通信。移动UI-A和移动UI-B可分别访问SE-A和SE-B。也就是说，移动UI表示能够与其他装置进行P2P通信并可访问SE的实体。
首先，激活包括在主装置中的移动UI-B(所有者移动UI的激活)，这将在下面描述。
移动UI-B根据应用启动、刷机检查等运行(a、启动应用和刷机检查)，并且诸如钥匙传送、钥匙共享等的菜单被选择(b、选择“共享我的钥匙”)。可以在运行应用时或者在根据服务开发需要特定功能时执行应用刷机检查。
如果根据移动UI-B的提供商或服务提供商的策略需要的话，执行用户认证处理(c、用户认证)，并可基于生物特征、已提前在主装置上注册的PIN等执行用户认证处理。移动UI-B开始在NFC P2P模式下操作(d、开始NFC P2P操作)。
在移动UI-B的激活处理中，除了刷机检查之外的其余操作可以是可选的，因此可根据移动UI-B的提供商的实现来执行或省略所述其余操作。移动UI-B支持一个或更多个应用刷机检查机制(移动UI应支持一个或更多个应用刷机检查机制)。
此外，激活包括在次级装置中的移动UI-A(用户移动UI的激活)，这将在下面描述。在图41A至图41C中，将注意，假设次级装置安装至少一个移动UI。
移动UI-A根据应用启动、刷机检查等运行(a、启动应用和刷机检查)，并且诸如钥匙共享等菜单被选择(b、选择“获得共享钥匙”)。可以在运行应用时或者在根据服务开发需要特定功能时执行应用刷机检查。移动UI-A开始在NFC P2P模式下操作(c、开始NFC P2P操作)。
在移动UI-A的激活处理中，除了刷机检查之外的其余操作可以是可选的，因此可根据移动UI-A的提供商的实现来执行或省略所述其余操作。移动UI-A支持一个或更多个应用刷机检查机制(移动UI应支持一个或更多个应用刷机检查机制)。
在次级装置和主装置之间执行从NFC到另一方案(例如，蓝牙、Wi-Fi等)的切换(NFC切换到蓝牙)。这将在下面描述。
移动UI-B向移动UI-A发送用于请求从NFC切换到蓝牙的消息(例如，切换请求消息)([01]切换请求(BT))。在从移动UI-B接收到切换请求消息时，移动UI-A选择切换到蓝牙，并向移动UI-B发送指示移动UI-A选择切换到蓝牙的消息(例如，切换选择消息)([02]切换选择(BT))。也就是说，主装置成为切换请求者，并且次级装置称为切换选择器。将注意，从NFC到蓝牙的切换的更具体的参数和情况与NFC连接切换技术规范[xx]和蓝牙安全简单配对规范[xx]中描述的相同。例如，“3cbb4363-dd09-4856-94e4-416605fa8fcb”将在切换时用作通用唯一标识符(UUID)。
根据切换请求消息和切换选择消息的交换，在移动UI-B和移动UI-A之间建立蓝牙连接([03]蓝牙连接建立)。
根据在移动UI-B和移动UI-A之间建立蓝牙连接，通过蓝牙连接在次级装置、主装置和服务提供商之间执行通信(通过蓝牙连接的通信)。
移动UI-B向服务提供商发送指示将发起接近触发钥匙共享(也就是说，指示将发起作为接近触摸的钥匙共享处理)的消息(例如，接近触发钥匙共享发起消息)([04]接近触发钥匙共享发起)。移动UI-B和服务提供商之间的接口可以以各种形式实现，并且这里将省略其详细描述。
在从移动UI-B接收到接近触发钥匙共享发起消息时，服务提供商产生随机数作为随机变量。随机数用于接收和验证次级装置的信息，这用于在产生次级装置的信息时通过使用随机数来防止次级装置的信息的重复使用。每当钥匙共享处理开始时都新产生随机数，因此可产生针对次级装置的唯一信息。
在图41A至图41C中，假设随机数在服务提供商中产生，然而，随机数可在主装置中产生。如果随机数在主装置中产生，则在主装置中产生的随机数将是在将要描述的操作[8]为服务提供商产生的，使得服务提供商可基于在主装置中产生的随机数来验证次级装置。
服务提供商向移动UI-B发送用于请求次级装置的信息的消息(例如，用户信息请求消息)([05]用户信息请求(随机数＝n))。这里，用户信息请求消息包括由服务提供商产生的随机数。在图41A至图41C中，将假设随机数被产生为“n”(随机数＝n)。
在从服务提供商接收到用户信息请求消息时，移动UI-B向移动UI-A发送用于请求用于次级装置的用户信息的写入请求消息([06]写入请求(n))。写入请求消息被用于请求用于钥匙共享的用户信息的消息，并包括通过用户信息请求消息接收的随机数。
在从移动UI-B接收到写入请求消息时，移动UI-A识别出用户信息被请求用于钥匙共享。因此，移动UI-A执行用于产生次级装置的用户信息的用户信息产生操作(用户信息的产生)。下面将描述用户信息产生操作。
移动UI-A产生包括公共密钥和私有密钥的公共/私有密钥对(U.Kpub，U.Kpriv)。U.Kpub表示由次级装置(即，用户装置)产生的公共密钥，U.Kpriv表示由次级装置(即，用户装置)产生的私有密钥。移动UI-A产生句柄h作为公共/私有密钥对的ID。在图41A至图41C中，句柄h用作公共/私有密钥对的ID，然而，句柄h可以是表示次级装置的ID。
移动UI-A基于公共/私有密钥对(U.Kpub，U.Kpriv)和句柄h产生用户信息。用户信息包括SE ID和MSISDN。MSISDN是用于在GSM或UMTS移动网络中识别用户终端的唯一号码，并且表示分配给移动电话或蜂窝电话中的SIM的电话号码。如果需要，用户信息还可包括次级装置的SE发放器信息、App版本、次级装置的IMEI、次级装置的SE的凭证、次级装置的型号名称、次级装置的制造商名称、次级装置的S/N等。用户信息被用于识别次级装置和次级装置的用户。例如，SE标识符、IMEI等被用于识别次级装置，并且MSISDN等被用于识别次级装置的用户。
移动UI-A利用作为次级装置的私有密钥的U.Kpriv对用户信息(n)、句柄h、作为次级装置的公共密钥的U.Kpub、以及随机数(即，n)进行签名以产生用户签名(即，Uinfo.Signature)。在图41A至图41C中，用户信息特征包括句柄h、用户信息(n)、作为次级装置的公共密钥的U.Kpub以及次级装置的用户签名Uinfo.Signature。
在产生用户信息之后，移动UI-A向移动UI-B发送对写入请求消息的响应消息(例如，写入响应)([07]写入响应())。这里，写入响应消息指示次级装置基于由服务提供商产生的随机数成功产生。
在从移动UI-A接收到写入响应消息时，移动UI-B向移动UI-A发送用于请求读取用户信息的消息(例如，读取请求消息)([08]读取请求(用户信息特征UUIC))。读取请求消息包括用户信息特征和主装置的UUID。
在从移动UI-B接收到读取请求消息时，移动UI-A向移动UI-B发送对读取请求消息的响应(例如，读取响应消息)([09]读取响应(用户信息特征))。这里，读取响应消息包括次级装置的用户信息特征。
在从移动UI-A接收到读取响应消息时，移动UI-B执行预确认操作([所有者预确认])。这里，下面将描述预确认操作。
移动UI-B基于从移动UI-A接收的次级装置的公共密钥U.Kpub来对次级装置的用户签名Uinfo.Signature进行验证。如果针对次级装置的用户签名Uinfo.Signature的验证结果成功，则移动UI-B输出主装置的用户信息。如果输出的主装置的用户信息被确认，则移动UI-B使用存储在主装置(即，SE-B)处的数字钥匙或具有与数字钥匙等同权限的钥匙对主装置的用户信息进行签名。如果主装置使用存储在SE-B处的数字钥匙，则主装置使用用于数字钥匙签名的APDU。已参照图32描述了用于数字钥匙签名的APDU。这里将省略对其的详细描述。
移动UI-B向服务提供商发送对用户信息请求消息的响应消息(例如，用户信息响应消息)([10]用户信息响应(用户信息、DK.Signature，(可选的))n))。用户信息响应消息包括次级装置的用户信息和数字钥匙签名。如果需要，用户信息响应可包括随机数(即，n)。
在从移动UI-B接收到用户信息响应消息时，服务提供商执行针对主装置的验证操作和针对次级装置的注册操作(所有者验证和用户登记)。下面将描述针对主装置的验证操作和针对次级装置的注册操作。
服务提供商通过对主装置的数字钥匙执行验证操作来确定主装置是否是实际拥有数字钥匙的所有者装置，或者确定主装置是否拥有作为所有者装置的适当的权限。服务提供商存储用从移动UI-B接收的次级装置的用户信息(即，主装置的数字钥匙)签名的次级装置的用户信息。服务提供商可临时存储次级装置的用户信息，并且次级装置的用户信息可包括SE ID、MSISDN、U.Kpub、句柄h等(b、U.Info、句柄、U.Kpub登记)。服务提供商产生将在次级装置和服务提供商之间共享的SHS，并通过使用次级装置的公共密钥U.Kpub对SHS进行加密来产生OTP(c、创建OTP＝enc(U.Kpub，SHS)。这里，SHS是用于验证次级装置的值。也就是说，服务提供商可通过检查次级装置是否拥有SHS等来验证次级装置。服务提供商通过主装置向次级装置传送SHS，并且OTP被用于防止除了次级装置之外的另一装置获得SHS。
在执行针对主装置的验证操作和针对次级装置的注册操作之后，服务提供商向移动UI-B发送指示针对次级装置的注册结果的消息(例如，用户注册结果消息)([11]用户注册结果(OTP))。如果用户注册结果消息指示次级装置被成功注册，则用户注册结果消息包括OTP。
在从服务提供商接收到用户注册结果消息时，移动UI-B向移动UI-A发送用于请求存储OTP的写入请求消息([12]写入请求(OTP))。写入请求消息包括用户注册结果消息中所包括的OTP。在从移动UI-B接收到写入请求消息时，移动UI-A存储OTP并发送指示OTP已被存储的消息(即，作为对写入请求消息的响应消息的写入响应消息)([13]写入响应())。
移动UI-A通过使用作为次级装置的私有密钥的U.KPriv对OTP进行解码来获取SHS(获取SHS；用户移动UI从OTP和U.KPriv计算SHS)。
尽管图41A至图41C将次级装置注册处理示出为一系列操作，但是图41A至图41C中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图42A和图42B是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置验证处理的信号流图。具体地，图42A和图42B示出在向次级装置提供DK之前检查次级装置是否拥有SHS，通过主装置确认次级装置以及与次级装置共享DK的次级装置验证处理。
在图42A和图42B中，将注意，服务提供商被示出为“汽车OEM后端”，主装置被示出为“所有者装置(DKS客户端)”，并且次级装置被示出为“用户装置(DKS服务器)”。此外，将注意，图42A和图42B以术语“汽车OEM后端”、“所有者装置(DKS客户端)”和“用户装置(DKS服务器)”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置包括SE和移动UI，并且主装置包括移动UI和SE。在图42A和图42B中，为方便起见，包括在次级装置中的SE和移动UI将分别被称为“SE-A”和“移动UI-A”，并且包括在主装置中的SE和移动UI将分别被称为“SE-B”和“移动UI-B”。
包括在获得SHS的次级装置中的移动UI-A向服务提供商请求作为共享数字钥匙的服务的钥匙共享服务。也就是说，次级装置向服务提供商发送用于请求钥匙共享服务的钥匙共享触发消息([14]由用户进行的钥匙共享触发(h))。钥匙共享触发消息包括句柄h，因此服务提供商可基于句柄h知道哪个次级装置请求钥匙共享服务。为了清楚地识别次级装置，除了句柄h以外，钥匙共享触发消息还可包括MSISDN、SE ID、IMEI等。
在从移动UI-A接收到钥匙共享触发消息时，服务提供商向次级装置的移动UI-A发送用于请求次级装置的用户验证请求消息([15]用户验证请求(质询))。用户验证请求消息包括质询。
如果移动UI-A基于包括在用户验证请求消息中的质询产生服务提供商预测的响应以向服务提供商发送响应，则服务提供商可确定次级装置被正常验证。
用户验证请求消息可包括针对主装置的质询和针对次级装置的质询。
为了仅向主装置传送关于用户ID的信息，服务提供商可使用主装置的公共密钥来对主装置的用户信息进行加密，并将经过加密的用户信息包括在用户验证请求消息中。在这种情况下，即使通过次级装置传送主装置的用户信息，也只有主装置可使用主装置的公共密钥对用户信息进行解码，因此可提高安全性能。在这种情况下，服务提供商预先拥有与主装置的私有密钥相应的公共密钥，并且与主装置的私有密钥相应的公共密钥可以例如在主装置和服务提供商之间的发起钥匙提供处理中被提供。
同时，图42A和图42B将描述用户验证请求消息包括一个质询，并且次级装置和主装置中的每个基于该质询产生针对所述一个质询的响应的情况。
在从服务提供商接收到用户验证请求消息时，移动UI-A执行用户质询响应计算操作(计算用户质询响应，cRes＝Hash(SHS，质询))。下面将描述用户质询响应计算操作。
移动UI-A基于包括在用户验证请求消息中的质询来计算质询响应。可如等式(1)中所表示来计算质询响应。
cRes＝Hash(SHS，质询)……等式(1)
在等式(1)中，cRes表示质询响应，并且将理解，如等式(1)中所表示的，质询响应是基于SHS和质询产生的。
可使用质询响应和次级装置的私有密钥U.Kpriv来产生附加签名。
同时，在次级装置、主装置和服务提供商之间执行主装置最终确认操作((可选地)，所有者最终确认)。下面将描述主装置最终确认操作。
服务提供商触发主装置最终确认操作([16]所有者确认触发)。根据服务提供商的触发，移动UI-B向移动UI-A发送用于请求主装置的质询的消息(例如，读取请求)([17]读取请求(所有者质询UUID))。读取请求消息包括主装置的UUID。
在从移动UI-B接收到读取请求消息时，移动UI-A计算质询响应，并向移动UI-B发送作为对读取请求的响应消息的读取响应消息([18]读取响应(所有者质询))。读取响应消息包括用户验证请求消息中包括的质询和计算出的质询响应。如果用户验证请求消息包括针对主装置的质询和针对次级装置的质询，而不是包括一个质询，则读取响应消息可包括针对主装置的质询。如果用户验证请求消息包括主装置的使用主装置的公共密钥进行加密的用户信息，则读取响应消息可包括主装置的使用主装置的公共密钥进行加密的用户信息。
在从移动UI-A接收到读取响应消息时，移动UI-B输出用于针对主装置的最终确认的确认参数，并识别针对确认参数的最终确认(a、在所有者的屏幕上显示最终确认请求；b、接收所有者的确认)。移动UI-B可通过在包括在主装置中的屏幕上显示用于针对主装置的最终确认的确认参数，来输出用于针对主装置的最终确认的确认参数。如果读取响应消息包括主装置的使用主装置的公共密钥进行加密的用户信息，则使用主装置的公共密钥对主装置的用户信息进行解码，并在包括在主装置中的屏幕上显示解码的结果。如果包括在主装置中的屏幕上显示的信息与图41A至图41C中描述的预确认操作中显示的信息不同，则预期发生诸如中间人攻击等的安全攻击，因此可停止对次级装置的共享钥匙提供。
在检测到对确认参数的最终确认时，移动UI-B基于存储在主装置处的数字钥匙或拥有与数字钥匙等同权限的钥匙来最终确认次级装置。这里，最终确认以主装置的质询响应(oRes)的形式产生，并通过次级装置传送到服务提供商，并且服务提供商对质询响应(oRes)进行验证。例如，可以如等式(2)中所表示的来计算质询响应(oRes)。
oRes＝Sign(质询，数字钥匙，cRes)……等式(2)
在主装置使用存储在主装置中包括的SE-B处的数字钥匙的情况下，主装置通过使用用于数字钥匙签名的APDU对质询和用户信息进行签名(sign)来产生主装置的质询响应(oRes)。已经参照图32描述了用于数字钥匙签名的APDU，这里将省略对其的详细描述。
可以使用散列(hash)等而不是签名来产生质询响应。在这种情况下，可以如例如等式(3)所表示的来计算质询响应(oRes)。
oRes＝Hash(质询，数字钥匙，cRes)……等式(3)
主装置的移动UI-B通过写入请求消息向移动UI-A发送产生的质询响应(oRes)([19]写入请求(所有者质询)]。在检测包括质询响应(oRes)的写入请求消息时，移动UI-A存储质询响应(oRes)，并发送对写入请求消息的响应消息(例如，写入响应消息)([20]写入响应)。
如上所述，在执行主装置最终确认操作之后，移动UI-A发送对用户验证请求消息的响应消息(例如，用户验证响应消息)([21]用户验证响应(cRes，oRes))。这里，用户验证响应消息包括由移动UI-A产生的质询响应(cRes)和从移动UI-B接收的质询响应(oRes)。如果不存在质询响应(oRes)，则用户验证响应可仅包括由移动UI-A产生的质询响应(cRes)。
在从移动UI-A接收到用户验证响应消息时，服务提供商对包括在用户验证响应消息中的质询响应(即，cRes和oRes)执行验证操作(用户验证：a、cRes验证；b、oRes验证)。如果针对cRes和oRes的验证结果成功，则服务提供商向次级装置提供数字钥匙。也就是说，在服务提供商和次级装置之间执行数字钥匙提供处理([22]根据CCC一般处理的数字钥匙提供)。
服务提供商可通过向主装置发送指示针对次级装置的数字钥匙提供结果的消息来使主装置识别数字钥匙被提供给次级装置([23]客户端数字钥匙提供结果的通知)。
尽管图42A和图42B将次级装置验证处理示出为一系列操作，但是图42A和图42B中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
用于DK共享服务的DK共享服务特征可如表26所示被表示。
表26
Figure GDA0002138630260000881
Figure GDA0002138630260000891
下面将描述表26中的每个特征。
表26中的随机数特征可如下表27中所示被表示。
表27
属性类型(属性ID) 定义(名称) 属性值类型 描述 状态
0x0100 随机数 uint8 随机值 M
用户信息特征可用于描述次级装置(即，用户智能装置)的信息，并且DKSC可从DKSS读取用户信息特征。例如，用户信息特征可用于主装置从次级装置读取用户信息。用户信息特征可用于指示将接收DK的次级装置的用户信息。
用户信息特征可如下表28中所示被表示。
表28
Figure GDA0002138630260000892
Figure GDA0002138630260000901
在表28中，SE标识符可用unit32或unit64实现。
在表28中，尽管MSISDN和SE标识符的状态被表示为“有条件”，但MSISDN和SE标识符的状态可以是“强制”。
在表28中，“C”指示相应的属性类型可实现为“有条件”，“O”指示相应的属性类型可实现为“可选”，“M”指示相应的属性类型可实现为“强制”。
用户公共密钥可类似于GPCS ECC密钥长度来实现，用户签名可类似于GPCS和B.3.1.1来实现，签名方案＝如PKCS#1中定义的RSASSA-PKCS-v1_5，散列(hash)函数是SHA-1。
MSISDN、SE标识符、IMEI和装置序列号中的至少一个可用作用户ID。
DKS OTP特征被用于DKS客户端(所有者装置)将OTP写入DKS服务器(用户装置)。DKS OTP特征可如下表29所示被表示。
表29
Figure GDA0002138630260000902
所有者质询特征被用于DKS客户端(所有者装置)从DKS服务器(用户装置)读取质询。所有者质询特征可如下表30所示被表示。
表30
Figure GDA0002138630260000903
Figure GDA0002138630260000911
所有者质询结果特征被用于DKS客户端(所有者装置)向DKS服务器(用户装置)写入所有者质询结果。所有者质询结果特征可如下表31所示被表示。
表31
Figure GDA0002138630260000912
图43示出根据本公开的实施例的在通信系统中注册次级装置的处理。具体地，图43示出在DK共享处理期间注册除了次级装置之外的诸如GPS信息、时间戳等的附加信息的处理，主装置和次级装置检查主装置和次级装置是否存在于同一区域并共享DK，因此可提供针对安全攻击更鲁棒的DK共享服务。
在图43中，将注意，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图43以术语“所有者”和“客户端”可与术语“主装置”和“次级装置”互换的形式被示出。
如图43所示，如果主装置和次级装置选择钥匙共享服务(1、运行应用(选择钥匙共享))，则执行敲击过程(2、敲击)，并且主装置在内部获得在敲击时间点的GPS信息和绝对时间(3、内部获得在敲击时间点的GPS信息和绝对时间(参考时间、参考GPS信息))。
次级装置获得次级装置的用户信息以及敲击时间点的绝对时间和GPS信息(4、获得信息(SE ID、客户端凭证)+在敲击时间点的GPS信息和绝对时间)。次级装置向主装置发送次级装置的用户信息，并且绝对时间和GPS信息被一起发送(5、传送客户端信息(SE ID、客户端凭证、时间、GPS信息))。
主装置将主装置的参考时间和参考GPS信息与从次级装置接收的时间和GPS信息进行比较(6、将参考时间和参考GPS信息与客户端的时间和GPS信息进行比较，并对客户端的时间和GPS信息进行验证)。如果次级装置和主装置存在于同一区域中，则主装置使用主装置的数字钥匙对主装置的用户信息进行签名(7、使用DK签名)，并在服务提供商处注册签名的用户信息(8、代替注册)。
为了使次级装置向主装置发送GPS信息和时间信息(例如，时间戳)，本公开的实施例如表32所示向获取用户信息(GetUserInformation)函数添加参数。存在与获取用户信息函数类似而并非获取用户信息函数本身的函数，指示GPS信息和时间信息的参数可被添加到该函数。
表32
Figure GDA0002138630260000921
图44是示出根据本公开的实施例的通信系统中的主装置的操作处理的流程图。具体地，图44示出在DK提供处理中执行的次级装置注册处理中在所有者预确认操作中验证GPS信息和时间戳的操作。
参照图44，将注意，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图44以术语“所有者”和“客户端”可与术语“主装置”和“次级装置”互换的形式被示出。
在图44中，对GPS信息和时间戳进行验证的操作可以在例如在数字钥匙提供处理中执行的次级装置注册处理中的所有者预确认操作处被执行。
在步骤4411中，主装置获得主装置的信息，例如，GPS信息和GPS时间戳。主装置的GPS信息被指示为“GPS_O”，并且主装置的GPS时间戳被指示为“To”。
在步骤4413中，主装置获得次级装置的信息，例如，GPS信息和GPS时间戳。次级装置的GPS信息被指示为“GPS_C”，并且次级装置的GPS时间戳被指示为“Tc”。
在步骤4415中，主装置确定主装置的GPS信息与次级装置的GPS信息之间的差是否小于第一阈值差值(例如，GSP_t)，以及主装置的GPS时间戳与次级装置的GPS时间戳之间的差是否小于第二阈值差值(例如，Tt)。如果主装置的GPS信息与次级装置的GPS信息之间的差不小于GSP_t，或者主装置的GPS时间戳与次级装置的GPS时间戳之间的差不小于Tt，则在步骤4417中，主装置确定针对次级装置的认证失败。
然而，如果主装置的GPS信息与次级装置的GPS信息之间的差小于GSP_t，并且主装置的GPS时间戳与次级装置的GPS时间戳之间的差小于Tt，则主装置在步骤4419中确定是否执行主装置确认。如果在步骤4419中执行主装置确认，则在步骤4421中，主装置向安全元件发送次级装置的信息，并且使用DK来对次级装置的信息进行签名。
然而，如果在步骤4419中不执行主装置确认，则该处理结束。
图45示出根据本公开的实施例的在通信系统中对用户应用进行验证的处理。具体地，在图45中，在共享DK的处理中通过存在于OS区域中的移动UI(＝应用)获得用户信息。因此，如果在OS上进行了刷机或者应用被黑客攻击感染，则从应用发送的用户信息的可靠性可能较低。
因此，用户安全元件可直接获得未通过移动UI的重要信息，并通过将所述重要信息与通过用户应用获得的信息进行比较，将重要信息用于用户应用的附加验证。
参照图45，将注意，主装置被示出为“所有者”，并且次级装置被示出为“客户端”。此外，将注意，图45以术语“所有者”和“客户端”可与术语“主装置”和“次级装置”互换的形式被示出。
在图45中，在共享数字钥匙的处理中通过存在于OS区域中的移动UI(＝应用)获得用户信息，因此，如果在OS上进行了刷机或者应用被黑客攻击等感染，则从应用传送的用户信息的可靠性可能较低。
因此，用户安全元件可直接获得未通过移动UI的重要信息，并通过将所述重要信息与通过用户应用获得的信息进行比较，将重要信息用于用户应用的附加验证。
主装置和次级装置运行应用以选择钥匙共享(1、运行应用(选择钥匙共享))，次级装置产生次级装置信息(产生客户端信息(应用的SE ID、凭证、GPS信息等)。次级装置向主装置发送产生的次级装置信息(3、传送客户端信息)，并且主装置读取存储在次级装置的安全元件处的次级装置的SE ID(4、读取客户端的SE的SE ID)。
主装置的应用将主装置的SE ID与安全元件的SE ID进行比较(5、将应用的SE ID与SE的SE ID进行比较)。主装置的应用对次级装置的凭证进行验证(6、验证凭证)，并且主装置的安全元件基于数字钥匙对SE ID和凭证进行签名(7、使用DK签名(SE ID+凭证))。主装置代替次级装置在服务提供商(图45中未示出)处注册次级装置的SE ID和凭证。
图46是示出根据本公开的实施例的在通信系统中对用户应用进行验证的处理的信号流图。
参照图46，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“客户端智能装置”。此外，将注意，图46以术语“OEM”、“所有者智能装置”和“客户端智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
在图46中，所有者终端请求客户端信息。客户端终端获得诸如SE ID和Client.PK(包括客户端终端的公共密钥)的信息，并准备第二NFC连接以再次执行敲击。这里，所有者终端作为NFC读取器操作，并且客户端终端的SE作为NFC标签操作。所有者终端的应用直接产生APDU命令，以通过NFC向客户端终端发送APDU命令。由所有者终端传送的APDU命令通过NFC控制器被直接传送到SE(也就是说，APDU命令不被传送到OS)。根据APDU命令(例如，GETDATA)，SE标识(SE ID)被响应作为APDU响应。所有者终端的应用将通过客户端终端的应用获得的SE ID和从客户端SE直接读取的SE ID进行比较。如果获得的SE ID与读取的SE ID相同，则将执行后续过程。后续过程可包括对诸如公共密钥、由客户端终端的应用发送的凭证等的其他信息进行验证和签名，并在服务器处注册经过验证和签名的信息的过程等。
这将被具体描述。
首先，例如，在次级装置4601和主装置4603之间建立NFC连接(4611)。次级装置4601的应用4606向主装置4603的应用4604发送次级装置4601的信息(例如，SE ID、次级装置4601的PK(即，Client.pk))(4613)。次级装置4601的应用4606可以可选地向主装置4603的应用4604发送GPS信息、时间戳和关于用于发送令牌的第二连接的信息。
在次级装置4601的安全元件4602和主装置4603的应用4604之间建立第二连接(4615)，并且主装置4603的应用4604向次级装置4601的安全元件4602发送GETDATA APDU请求(4617)。次级装置4601的安全元件4602向主装置4603的应用4604发送对GETDATA APDU请求的响应(4619)。该响应可包括次级装置4601的安全元件4602的SE ID。
主装置4603的应用程序4604对从次级装置4601的安全元件4602传送的SE ID和次级装置信息执行验证操作(4621)。然后，通过OMAPI在主装置4603的应用4604和主装置4603的安全元件4605之间建立信道(4623)，并且主装置4603的应用4604向主装置4603的安全元件4605发送执行安全操作APDU命令(4625)。执行安全操作APDU命令可包括用于请求计算数字签名的命令。
主装置4603的安全元件4605基于输入数据和共享数字钥匙(DK.Sharing)来计算数字签名(DS)(4627)。输入数据可以是次级装置4601的信息和数字钥匙标识符(DK ID)。主装置4603的安全元件4605向主装置4603的应用4604传送包括计算出的数字签名的响应(4629)。
尽管图46将信号发送/接收操作示出为一系列操作，但是图46中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图47是示出根据本公开的实施例的在通信系统中提供DK的处理中包括的次级装置注册处理的信号流图。具体地，图47示出次级装置和次级装置的信息如何在服务提供商处被注册。
参照图47，图47中的次级装置注册处理在以下方面与如上所述的其他次级装置注册处理的示例不同。也就是说，如上所述的次级装置注册处理的示例仅在简单设置中使用NFC，并且通过诸如BT等的第二连接发送和接收主要数据。然而，在图47中的次级装置注册处理中，通过NFC执行客户端注册和客户端信息的获得，并且通过诸如BT等的第二连接等执行后续过程。
两个装置(例如，客户端装置(即，次级装置)和所有者装置(即，主装置))开始在NFC P2P模式下操作。
将理解，使用NFC论坛数据交换格式(NDEF)协议来交换随机数和客户端信息。
图47中的次级装置注册处理指示次级装置和次级装置的信息如何在服务提供商处被注册。
在图47中，将注意，服务提供商被示出为“汽车OEM后端”，主装置被示出为“所有者装置”，并且次级装置被示出为“客户端装置”。此外，将注意，图47以术语“汽车OEM后端”、“所有者装置”和“客户端装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
次级装置包括SE和移动UI，并且主装置包括移动UI和SE。在图47中，为方便起见，包括在次级装置中的SE和移动UI将分别被称为“SE-A”和“移动UI-A”，并且包括在主装置中的SE和移动UI将分别被称为“SE-B”和“移动UI-B”。移动UI-A和移动UI-B可分别访问SE-A和SE-B。也就是说，移动UI表示能够与其他装置进行P2P通信并可访问SE的实体。
将注意，图47中的次级装置注册处理与图33A和图33B中的次级装置注册处理类似，然而，图47中的次级装置注册处理和图33A和图33B中的次级装置注册处理在以下方面不同。
首先，主装置在获得次级装置的用户信息之前不从服务提供商接收随机数。
其次，主装置不预先接收随机数，包括在主装置中的移动UI-B产生随机数值以将随机数值传送到包括在次级装置中的移动UI-A，并且在向服务提供商传送次级装置的用户信息时将随机数值连同次级装置的用户信息传送到服务提供商，从而服务提供商可验证所述用户信息。
尽管图47将次级装置注册处理示出为一系列操作，但是图47中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图48示出根据本公开的实施例的通信系统中的TEE。
参照图48，主处理器的一部分被划分为作为安全区域的TEE和作为一般区域的丰富执行环境。安全区域执行存储和处理相对敏感的信息。可通过在安全区域上运行单独的安全OS来配置TEE，其中，所述单独的安全OS与芯片内的主OS分离。从REE到TEE的访问是不可能的，并且可通过TEE中定义的API来有限地访问安全资源。
在图48中，TA被安装在TEE上并在TEE上运行，并且客户端应用(CA)被安装在REE上并在REE上运行，并且使用TA中提供的功能。
图49是示出根据本公开的实施例的在通信系统中在TEE中产生用户信息的处理的信号流图。
参照图49中，将注意，主装置被示出为“所有者智能装置”，并且次级装置被示出为“用户智能装置”。此外，将注意，图49以术语“所有者智能装置”和“用户智能装置”可与术语“主装置”和“次级装置”互换的形式被示出。
首先，在所有者装置和用户装置之间产生NFC P2P会话(NFC P2P会话创建)，基于PKI建立应用到应用安全信道，并且所有者装置向用户装置发送钥匙共享发起和装置信息请求(1、钥匙共享发起+装置信息请求)。用户应用使用TEE客户端向TEE区域内的TA请求用户信息(2、用户信息请求)。TA直接访问SE以获取SE ID(3、获取SE ID；4、SE ID)。TA对产生的装置信息进行签名(5、装置信息＝Sig(SApp.SK，SE ID)。TA可产生将用于实时签名和加密的密钥对，或者使用由TA开发人员安装的凭证的密钥以用于签名和加密。TA向客户端应用(CA)传送签名(6、rsp)。在这种情况下，用户信息在TEE中产生比在REE中产生更安全，因此用户信息的可靠性可增强。
尽管图49将在TEE中产生用户信息的处理示出为一系列操作，但是图49中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图50是示出根据本公开的实施例的在通信系统中在主装置中使用TEE执行担保操作(assuring operation)的处理的信号流图。
参照图50，将注意，服务提供商被示出为“OEM”，主装置被示出为“所有者智能装置”，并且次级装置被示出为“用户智能装置”。此外，将注意，图50以术语“OEM”、“所有者智能装置”和“用户智能装置”可与术语“服务提供商”、“主装置”和“次级装置”互换的形式被示出。
首先，在TEE中获得具有与数字钥匙类似的级别的用于担保钥匙共享服务的密钥。在图50中，服务提供商(即，OEM)基于CCC标准在SE处存储数字钥匙(1、插入数字钥匙)。OEM通过所有者应用使TA产生用于担保DK共享服务的密钥对(2、触发数字钥匙共享服务的密钥产生)。TA产生用于DK共享服务的密钥对，并在OEM服务器处注册公共密钥(3、DK共享钥匙请求；4、产生DK Shr密钥对(P.Shr.SK、P.Shr.PK)；5、P.Shr.PK)。可存在用于安装和插入用于担保DK共享服务的密钥的各种方案。例如，OEM可在插入数字钥匙时将密钥直接插入TA。
尽管图50将使用TEE执行担保操作的处理示出为一系列操作，但是图50中的各种操作可以重叠、并行发生、以不同顺序发生或多次发生。
图51是示出根据本公开的实施例的在通信系统中使用存储在TA处的用于担保DK共享服务的密钥来执行签名操作的处理的信号流图。具体地，在图51中，TA而不是SE执行对客户端信息的签名操作。
参照图51，将注意，主装置被示出为“所有者智能装置”，并且次级装置被示出为“用户智能装置”。此外，将注意，图51以术语“所有者智能装置”和“用户智能装置”可与术语“主装置”和“次级装置”互换的形式被示出。
首先，与SE相比，TEE具有更好的计算处理能力，因此与SE相比，TEE可添加更快更多种功能。
在图51中，方法A示出从REE上的一般应用获得用户信息的方法，方法B示出通过在TA之间连接诸如BT等的连接来直接从用户终端的TA获得用户信息的方法。
在如上所述的本公开的各种实施例中提出的数字钥匙共享处理中，SE执行用于共享的签名操作，然而，在图51中，TA执行针对客户端信息的签名操作。
在这种情况下，在[6b]操作，TA与SE相比具有更快的计算速度，因此可实现TA直接针对用户信息执行验证。
本公开的上述实施例能够在通信系统中提供和管理安全信息，在通信系统中共享安全信息，增强在通信系统中对共享安全信息的装置的认证，在没有在通信系统中的服务器处注册帐户情况下获得安全信息，并且增强通信系统中的安全信息的可靠性。
本公开的上述实施例还可实现为非暂时性计算机可读记录介质上的计算机可读代码。非暂时性计算机可读记录介质可包括可存储其后可由计算机系统读取的数据的任何数据存储装置。非暂时性计算机可读记录介质的示例包括只读存储器(ROM)、随机存取存储器(RAM)、紧凑盘(CD)-ROM、磁带、软盘、光学数据存储装置和载波(诸如通过互联网的数据传输)。非暂时性计算机可读记录介质还可分布在连接到计算机系统的网络上，使得计算机可读代码以分布式方式被存储和执行。此外，用于实现本公开的功能程序、代码和代码段可由本公开所属领域的程序员来解释。
根据本公开的上述实施例的方法和设备可通过硬件、软件和/或它们的组合来实现。软件可存储在非易失性存储器中，例如，可擦除或可重写ROM、存储器(例如，RAM)、存储器芯片、存储器装置或存储器集成电路(IC)或光学或磁性可记录非暂时性机器可读(例如，计算机可读)存储介质(例如，CD、DVD、磁盘、磁带等)。
根据本公开的上述实施例的方法和设备可由包括控制器和存储器的计算机或移动终端实现，并且存储器可以是非暂时性机器可读(例如，计算机可读)的适用于存储包括用于实现本公开的各种实施例的指令的程序的存储介质的示例。
本公开可包括用于实现由所附权利要求限定的设备和方法的代码的程序，以及存储该程序的非暂时性机器可读(例如，计算机可读)存储介质。可经由诸如通过有线和/或无线连接发送的通信信号的任何介质电子地发送所述程序，并且本公开可包括它们的等同物。
根据本公开的实施例的设备可从程序提供装置接收程序，其中，所述程序提供装置经由有线或无线连接到所述设备并存储所述程序。程序提供装置可包括：存储器，用于存储指令、内容保护方法所需的信息等，其中，所述指令指示执行已安装的内容保护方法；通信单元，用于与图形处理装置执行有线或无线通信；以及控制器，用于基于图形处理装置的请求向发送/接收装置发送将相关程序，或者自动向发送/接收装置发送将相关程序。
尽管已经参考本公开的特定实施例示出和描述了本公开，但是本领域技术人员将理解，在不脱离由所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以在形式和细节上进行各种改变。

Claims (14)

1.一种通信系统中的第一装置的方法，所述方法包括：
从第二装置接收请求共享第一装置的安全信息的第一消息，其中，第一消息包括第二装置的信息；
使用在第一装置与服务提供商之间共享的安全信息生成针对第二装置的担保信息；
向服务提供商发送请求注册第二装置的第二消息，其中，第二消息包括所述担保信息；
从服务提供商接收第三消息，其中，第三消息包括针对第二装置的用于共享第一装置的安全信息的认证信息；以及
向第二装置发送第四消息，其中，第四消息包括所述认证信息。
2.如权利要求1所述的方法，还包括：基于第二装置的信息，验证第二装置。
3.一种通信系统中的第一装置的方法，所述方法包括：
向服务提供商发送请求共享第一装置的安全信息的第一消息；
从服务提供商接收第二消息，其中，第二消息包括针对第二装置的用于共享第一装置的安全信息的第一认证信息；
基于第一认证信息和第一装置的安全信息，产生针对第二装置的用于共享第一装置的安全信息的第二认证信息；以及
向第二装置发送包括第二认证信息的第三消息，
其中，第二认证信息被用于与服务提供商执行认证操作。
4.如权利要求3所述的方法，其中，向第二装置发送包括第二认证信息的第三消息的步骤包括：
与第二装置建立连接；以及
通过建立的连接向第二装置发送第二认证信息。
5.一种通信系统中的第二装置的方法，所述方法包括：
向第一装置发送请求共享第一装置的安全信息的第一消息，其中，第一消息包括第二装置的信息；
从第一装置接收第二消息，其中，第二消息包括针对第二装置的用于共享第一装置的安全信息的认证信息；
基于所述认证信息与服务提供商执行认证操作；以及
从服务提供商接收第三消息，其中，第三消息包括第一装置的安全信息。
6.如权利要求5所述的方法，还包括：在与服务提供商执行认证操作之后，请求服务提供商共享第一装置的安全信息。
7.一种通信系统中的第二装置的方法，所述方法包括：
与第一装置建立连接；
基于第一认证信息和第一装置的安全信息，从第一装置接收第一消息，其中，第一消息包括针对第二装置的用于共享第一装置的安全信息的第二认证信息；
向服务提供商发送请求共享第一装置的安全信息的第二消息；以及
从服务提供商接收第一装置的安全信息，
其中，第二认证信息被用于与服务提供商执行认证操作。
8.一种通信系统中的服务提供商的方法，所述方法包括：
从第一装置接收请求注册第二装置的第一消息，其中，第一消息包括针对第二装置的担保信息；
基于所述担保信息，注册第二装置；
产生针对第二装置的用于共享第一装置的安全信息的认证信息；
向第一装置发送第二消息，其中，第二消息包括针对第二装置的用于共享第一装置的安全信息的所述认证信息；
基于所述认证信息与第二装置执行认证操作；以及
向第二装置发送第三消息，其中，第三消息包括第一装置的安全信息。
9.一种通信系统中的服务提供商的方法，所述方法包括：
从第一装置接收请求共享第一装置的安全信息的第一消息；
产生针对第二装置的用于共享第一装置的安全信息的第一认证信息；
向第一装置发送第二消息，其中，第二消息包括针对第二装置的用于共享第一装置的安全信息的所述第一认证信息；
基于第二认证信息，从第二装置接收请求共享第一装置的安全信息的第三消息；以及
向第二装置发送第一装置的安全信息，
其中，第二认证信息被用于与服务提供商执行认证操作。
10.一种通信系统中的第一装置，第一装置包括：
收发器；和
处理器，被配置为：
经由收发器从第二装置接收请求共享第一装置的安全信息的第一消息，其中，第一消息包括第二装置的信息；
使用在第一装置与服务提供商之间共享的安全信息生成针对第二装置的担保信息；
经由收发器向服务提供商发送请求注册第二装置的第二消息，其中，第二消息包括所述担保信息；
经由收发器从服务提供商接收第三消息，其中，第三消息包括针对第二装置的用于共享第一装置的安全信息的认证信息；以及
经由收发器向第二装置发送包括所述认证信息的第四消息。
11.如权利要求10所述的第一装置，其中，处理器还被配置为：基于第二装置的信息，验证第二装置。
12.一种第一装置，被配置为执行权利要求3和权利要求4所述的方法中的一种方法。
13.一种第二装置，被配置为执行权利要求5至权利要求7所述的方法中的一种方法。
14.一种服务提供商，被配置为执行权利要求8至权利要求9所述的方法中的一种方法。
CN201880007940.XA 2017-01-20 2018-01-22 用于在通信系统中提供和管理安全信息的设备和方法 Active CN110235424B (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201762448551P 2017-01-20 2017-01-20
US62/448,551 2017-01-20
US201762523513P 2017-06-22 2017-06-22
US62/523,513 2017-06-22
KR10-2017-0119878 2017-09-18
KR1020170119878A KR20180086118A (ko) 2017-01-20 2017-09-18 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법
PCT/KR2018/000962 WO2018135919A1 (en) 2017-01-20 2018-01-22 Apparatus and method for providing and managing security information in communication system

Publications (2)

Publication Number Publication Date
CN110235424A CN110235424A (zh) 2019-09-13
CN110235424B true CN110235424B (zh) 2022-03-08

Family

ID=62907338

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880007940.XA Active CN110235424B (zh) 2017-01-20 2018-01-22 用于在通信系统中提供和管理安全信息的设备和方法

Country Status (3)

Country Link
US (1) US10805287B2 (zh)
CN (1) CN110235424B (zh)
WO (1) WO2018135919A1 (zh)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9779596B2 (en) 2012-10-24 2017-10-03 Apple Inc. Devices and methods for locating accessories of an electronic device
US10929843B2 (en) * 2014-05-06 2021-02-23 Apple Inc. Storage of credential service provider data in a security domain of a secure element
CN105827655B (zh) * 2016-05-27 2019-04-16 飞天诚信科技股份有限公司 一种智能密钥设备及其工作方法
US11847241B1 (en) * 2018-04-20 2023-12-19 Amazon Technologies, Inc. Management of service permissions
US11777936B2 (en) 2018-06-11 2023-10-03 Apple Inc. Friend key sharing
KR102695457B1 (ko) * 2018-08-31 2024-08-14 삼성전자주식회사 디지털 키를 처리하는 전자 디바이스 및 그 동작 방법
US11641563B2 (en) 2018-09-28 2023-05-02 Apple Inc. System and method for locating wireless accessories
WO2020105892A1 (ko) * 2018-11-20 2020-05-28 삼성전자 주식회사 디바이스가 디지털 키를 공유하는 방법
KR20200089562A (ko) 2019-01-17 2020-07-27 삼성전자주식회사 공유된 키를 등록하기 위한 방법 및 장치
KR20200090490A (ko) * 2019-01-21 2020-07-29 삼성전자주식회사 디지털 키 공유 시스템에서 이모빌라이저 토큰을 업데이트하는 장치 및 방법
EP3933154B1 (en) * 2019-02-25 2024-06-05 Honda Motor Co., Ltd. Vehicle, vehicle onboard device, and management method
CN113812175A (zh) * 2019-04-17 2021-12-17 苹果公司 为无线附件共享密钥
GB2584527B (en) * 2019-05-10 2021-12-08 Advanced Risc Mach Ltd Machine to machine communications
US11637745B2 (en) * 2019-09-11 2023-04-25 Hand Held Products, Inc. Configuring a remote electronic device by a peer electronic device in a networked environment
WO2021046822A1 (zh) * 2019-09-12 2021-03-18 Oppo广东移动通信有限公司 设备激活方法、终端设备及计算机存储介质
CN111083670A (zh) * 2019-12-31 2020-04-28 东风小康汽车有限公司重庆分公司 一种基于智能钥匙的车辆使用方法及装置
EP4106357A4 (en) * 2020-03-09 2023-07-12 Huawei Technologies Co., Ltd. METHOD FOR CONNECTING TO AN ON-BOARD COMPUTER SYSTEM AND ASSOCIATED DEVICE
US11765182B2 (en) * 2020-10-23 2023-09-19 Microsoft Technology Licensing, Llc Location-aware authentication
US12073705B2 (en) 2021-05-07 2024-08-27 Apple Inc. Separation alerts for notification while traveling
CN113573239B (zh) * 2021-06-15 2022-07-01 荣耀终端有限公司 一种虚拟卡切换方法、电子设备及可穿戴设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101939746A (zh) * 2007-12-10 2011-01-05 菲尔爱迪(私人)有限公司 用于管理移动计算设备上的软件应用程序的方法和系统
CN103442328A (zh) * 2013-09-02 2013-12-11 北京鹏通高科科技有限公司 一种物联网终端的服务质量控制方法和系统
CN203399141U (zh) * 2013-09-06 2014-01-15 中国工商银行股份有限公司 一种信息通道安全认证装置
CN105684482A (zh) * 2013-10-17 2016-06-15 阿姆Ip有限公司 为代理设备建立受信任身份的方法
CN106302502A (zh) * 2016-04-03 2017-01-04 北京动石科技有限公司 一种安全访问认证处理方法、用户终端和服务端
CN106330854A (zh) * 2015-06-30 2017-01-11 三星电子株式会社 用于执行认证的方法及其电子装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2853200T3 (es) * 2009-05-29 2021-09-15 Alcatel Lucent Sistema y procedimiento para acceder a contenido digital privado
EP2337300B1 (en) 2009-12-21 2014-01-22 BlackBerry Limited Method of Securely Transferring Services Between Mobile Devices
CN101867589B (zh) * 2010-07-21 2012-11-28 深圳大学 一种网络身份认证服务器及其认证方法与系统
US9185116B2 (en) * 2010-11-10 2015-11-10 Sony Corporation Methods and systems for use in providing access through a secondary device to services intended for a primary device
US9365188B1 (en) * 2011-04-22 2016-06-14 Angel A. Penilla Methods and systems for using cloud services to assign e-keys to access vehicles
JP5494603B2 (ja) 2011-09-29 2014-05-21 沖電気工業株式会社 セキュリティ処理代行システム
CN104247467A (zh) * 2012-02-17 2014-12-24 英特托拉斯技术公司 用于交通工具策略施行的方法和系统
CN102932790B (zh) * 2012-10-31 2015-04-22 江苏博智软件科技有限公司 一种基于移动通信网络的物联网安全认证方法
US20140156528A1 (en) 2012-11-30 2014-06-05 Stephen Frechette Method and system for secure mobile payment of a vendor or service provider via a demand draft
US20140365781A1 (en) 2013-06-07 2014-12-11 Technische Universitaet Darmstadt Receiving a Delegated Token, Issuing a Delegated Token, Authenticating a Delegated User, and Issuing a User-Specific Token for a Resource
US9563998B2 (en) 2014-06-11 2017-02-07 Veridium Ip Limited System and method for facilitating user access to vehicles based on biometric information
US10384643B2 (en) 2015-01-14 2019-08-20 GM Global Technology Operations LLC Virtual keyfob for vehicle sharing
US9843572B2 (en) * 2015-06-29 2017-12-12 Airwatch Llc Distributing an authentication key to an application installation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101939746A (zh) * 2007-12-10 2011-01-05 菲尔爱迪(私人)有限公司 用于管理移动计算设备上的软件应用程序的方法和系统
CN103442328A (zh) * 2013-09-02 2013-12-11 北京鹏通高科科技有限公司 一种物联网终端的服务质量控制方法和系统
CN203399141U (zh) * 2013-09-06 2014-01-15 中国工商银行股份有限公司 一种信息通道安全认证装置
CN105684482A (zh) * 2013-10-17 2016-06-15 阿姆Ip有限公司 为代理设备建立受信任身份的方法
CN106330854A (zh) * 2015-06-30 2017-01-11 三星电子株式会社 用于执行认证的方法及其电子装置
CN106302502A (zh) * 2016-04-03 2017-01-04 北京动石科技有限公司 一种安全访问认证处理方法、用户终端和服务端

Also Published As

Publication number Publication date
CN110235424A (zh) 2019-09-13
US20180213405A1 (en) 2018-07-26
US10805287B2 (en) 2020-10-13
WO2018135919A1 (en) 2018-07-26

Similar Documents

Publication Publication Date Title
CN110235424B (zh) 用于在通信系统中提供和管理安全信息的设备和方法
EP3520363B1 (en) Apparatuses and methods for providing and managing security information in communication system
US10887318B2 (en) Method and apparatus for downloading profile on embedded universal integrated circuit card of terminal
US11943615B2 (en) Method and apparatus for discussing digital certificate by ESIM terminal and server
WO2018077232A1 (zh) 一种网络认证方法、相关设备及系统
EP3293993B1 (en) Method and apparatus for providing profile
CN110024426B (zh) 通过eSIM进行访问控制的装置及方法
KR101491392B1 (ko) 간접적인 디바이스 통신
CN104427501B (zh) 网络接入方法、装置和系统
EP3595247A1 (en) Identity authentication method and system, server and terminal
CN105284178A (zh) 配置无线附件设备
CN105472192A (zh) 实现控制安全授权和分享的智能设备、终端设备及方法
US11963261B2 (en) Method and apparatus for recovering profile in case of device change failure
CN114762290A (zh) 对数字密钥进行管理的方法和电子装置
US8989380B1 (en) Controlling communication of a wireless communication device
JP2018520526A (ja) デバイスコンテンツプロビジョニングシステム
US10560448B1 (en) One-touch secure on-boarding of OOB IoT devices
CN118632228A (zh) 用于授权远程简档管理的方法、装置和系统
US20240054836A1 (en) Physical access control system with secure relay
CN113455025A (zh) Ssp终端在捆绑包下载过程和esim配置文件下载过程之间进行互操作的方法
CN112567772B (zh) 用于授权远程简档管理的方法、装置和系统
JP2024501696A (ja) ロック解除通知のインテリジェントな構成

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant