在智能卡和终端之间进行安全通信的方法和设备的制作方法

文档序号:7948369阅读:337来源:国知局
专利名称:在智能卡和终端之间进行安全通信的方法和设备的制作方法
相关申请的交叉引用本申请涉及2003年11月17日提交的、序号为10/715,970、标题为“Method and System To Provide A Trusted Channel Within AComputer System ForA SIM Device”的共同待决的美国专利申请以及涉及2004年6月29日提交的、序号为10/881,658、标题为“A SystemIncluding a Wireless Wide Area Network(WWAN)Module Associatedwith an External Identity Module Reader and Approach for Certifying theWWAN Module”的共同待决的美国专利申请,序号为10/715,970的申请的案卷号为42.P18073,已经转让给本发明的受让人,序号为10/881,658的申请的案卷号为42.P18589,也已经转让给本发明的受让人。
背景技术
本发明的一个实施例涉及电子系统领域,具体而言,涉及一种用于在终端和智能卡及智能卡读取器中的一个之间进行安全通信的方法。传统开放式个人计算(PC)平台上由病毒和其它攻击引起的不安全性是众所周知的。可信计算组(TCG)正在开发增强这种开放式PC平台安全性的规范。现有规范定义了若干种改善PC平台安全性的机制。假设这些平台支持旧有的应用程序,然而,与这些平台一起工作的一些外围设备和/或其它设备仍可能会受病毒和/或攻击的影响,除非设计它们的接口来提供足够的安全性。


以下将通过附图对本发明进行说明,附图是举例说明性的,而没有限制性意味,在附图中,相同的标记表示相同的部件,其中 图1中的流程图示出了在终端与智能卡和智能卡读取器之一之间建立安全通信的一个实施例的方法; 图2中的框图示出了有利于实现一个实施例的本地链路传输层保护协议的示例性环境; 图3中的框图示出了按照一个实施例的智能卡(如,SIM、USIM、UICC或Java卡)的体系结构; 图4是一个实施例的APDU-TLS中的应用程序APDU的封装示意图; 图5中的状态图示出了一个实施例的本地链路传输层保护协议的示例性状态; 图6是启动本地链路传输层保护协议会话的一个实施例的协议的示意图; 图7是按照一个实施例的握手过程协议的示意图;以及 图8是经由可信隧道交换数据的一个实施例的协议的示意图。
具体实施例方式描述了在智能卡或智能卡读取器与终端之间进行安全通信的一种方法和设备。在以下描述中,出于说明性目的,描述了特定的组件、软件和硬件模块、系统、协议以及组成要素等。然而,需要明白的是,例如,其它实施例可用于其它类型的组件、软件和/或硬件模块、系统协议和/或组成要素等。
围绕“一个实施例”、“某一实施例”、“范例性实施例”和“各种实施例”等进行描述说明本发明的一个或多个实施例可能包括特定的特征、结构或特点,但不是每个实施例都必须包括特定的特征、结构或特点。另外,反复使用“在一个实施例中”这样的措辞尽管有可能指同一实施例,但也不是必然的。
为了便于说明,可将本发明实施例的多个方面描述为用硬件、固件或软件来实现。需要明白的是,这些方面也可用不同的媒介来实现。
目前,如何利用GSM(全球移动通信系统)SIM(用户识别模块)或USIM(通用SIM)卡对使用膝上型(laptop)PC平台或其它移动计算设备的无线局域网(WLAN)用户进行验证很受关注。为确保其实现,与使用硬件凭证(如SIM/USIM卡、智能卡和类似的安全性标记)相关的安全性问题需要重点考虑。具体而言,与这些设备相关联的一些现有的凭证访问协议是针对封闭和/或较少恶意环境而设计的,并且它们可能需要得到增强例如才能阻止与开放式平台如PC相关联的安全性威胁。
此外,平台之间的连接(本地链路)也需要足够级别的保护。本发明的实施例提供了一种对处于具有智能卡能力的平台(软件或硬件)之间的本地链路进行保护的方法。参照各种实施例描述的保护方法相对强壮并能在两个平台之间进行相互认证。
参照图1,为了在智能卡(例如ICC或UICC)和/或相关读取器以及平台(在这里也称为终端)之间进行安全通信,一个实施例的方法包括在框105中,接收要在智能卡和终端之间启动本地链路传输层保护协议会话的命令。在框110中,响应所述命令,智能卡与终端参与包括相互认证的握手过程。握手过程成功完成后,在框115中,建立可信隧道并且经由可信隧道从智能卡向终端提供数据。然后,按照本地链路传输层协议,可进行智能卡和终端之间的通信。
作为本文所用的术语,智能卡和/或通用集成电路卡(UICC),可能包括,例如,一个或多个用户识别模块(SIM)卡、通用SIM(USIM)卡、可拆卸用户识别模块(RUIM)、IP多媒体服务识别模块(ISIM)、无线识别模块(WIM)、Java卡和/或其它凭证卡、功能或模块,并且在本文中也可称为凭证、凭证模块或卡、令牌、机器或识别模块或卡。
本文使用的术语智能卡读取器指任何包括智能卡和能从智能卡访问数据的任何设备、平台或系统。例子可包括蜂窝/移动电话、个人数字助理、笔记本平台或任何其它持有智能卡的设备。
作为本文所用的术语,终端指电子系统或平台,例如,膝上电脑、笔记本或其它类型的移动计算系统,如个人数字助理、台式机或企业计算系统等,并且也可被称为平台或机器。其它类型的电子系统落入各种实施例的范围之内。
图2是示例性环境200的高级框图,它有利于实现一个或多个实施例的安全通信方法。环境200包括终端205和智能卡和/或智能卡读取器210,如上所述。一些实施例的终端205包括可信硬件和软件(未示出)并能够建立受保护分区从而提供软件应用程序的受保护执行。各种实施例的可信硬件和软件还可包括与智能卡210和终端205二者中一个或两个相关联的安全存储器。对于终端205是移动电子系统的实施例来说,终端可包括电池或电池连接器212,从而电池为终端供电,而不是用AC电源来供电。
本文所用的涉及系统、软件、固件和/或硬件的术语“可信”说明相关联的硬件、固件和/或软件的源是已知的并可进行验证;其状态可在任何时间点进行度量和验证;其按照预期方式运转。本文所用的涉及存储的术语“安全的”或“受保护的”,例如,说明相关联的存储器或元件具有足够的与其相关的保护,从而能阻止不可信或未授权源的访问。
对于一些实施例来说,如上所述,智能卡210可包括在模块内,例如,通用无线分组业务(GPRS)卡模块、蜂窝电话、个人数字助理(PDA)等和/或可包括在终端中或经由另一类智能卡读取器连接到终端。参照各种实施例的智能卡210可基本遵循ISO/IEC 7816第4部分、跨行业交换命令和ETSI TS 102 221版本4.3.0规范(UICC)和/或这种规范的类似和/或未来版本,并且对于一些实施例来说,可包括附加的公共密钥基础设施(PKI)支持,下面还将对此进行详细描述。遵循ISO/IEC 7816第4部分和/或ETSI TS 102 221版本4.3.0的智能卡支持使用分组的数据通信,所述分组称为应用协议数据单元(APDU)。此外,一些实施例的智能卡(ICC或UICC)支持T=0协议并从C-APDU(命令-APDU)到C-TPDU(命令-传输协议数据单元)的映射。
对于一些实施例来说,终端205可支持ISO 7816第4部分(ISO7816-4)APDU和ETSI TS 102 221版本4.3.0等所规定的UICC-终端接口APDU。APDU接口不一定为物理接口。如果智能卡嵌入在GPRS(通用无线分组业务)模块中,或可通过蓝牙TM本地接口进行远程访问,例如,下面详细描述的一些实施例的本地链路传输层保护协议只要底层传输提供可靠消息传递就可工作。
终端205以及智能卡和/或智能卡读取器210通过链路(或总线)215和220进行通信。对于这种实施例来说,链路215代表终端205和智能卡210之间的在一些实施例的安全通信协议以外的数据通信,而链路220代表终端205和智能卡210之间的受保护数据通信。
链路215和220(或链路215和220代表的单个链路/总线)可用各种方式中任何一种来实现。例如,以下可提供链路无线链路如蓝牙TM本地接口、无线局域网(WLAN)连接(如802.11a/b/g)或工作在相同频带(2.4GHz ISM(工业、科技或医学)频带)上的另一类型无线链路例如微波链路、HomeRF LAN、依据IEEE 802.15.1的链路(无线个域网(WPAN))、另一新兴IEEE标准链路,例如ZigBee链路或无线电话链路。有线本地连接如通用串行总线(USB)连接也可用于一些实施例。
对于示例性的环境200来说,终端205存储或可访问主机应用程序225,当执行时主机应用程序225可与智能卡210上的凭证应用程序227进行通信。对于智能卡210是或包括用户识别模块(SIM)的实施例来说,主机应用程序225可以是例如EAP-SIM(可扩展认证协议-SIM)应用程序,而凭证应用程序可以是无线局域网-SIM(WLAN-SIM)应用程序。基于的主机和/或智能卡的其它类型应用程序以及应用程序之间相关联的通信落入各种实施例的范围内。
需要明白的是,智能卡210和终端205中一个或两个可包括、连接到或可访问图2中未示出的部件。例如,对于终端205是个人计算系统的实施例来说,终端205可包括处理器、芯片组和其它通常包括在个人计算系统内的组件和/或模块。
为了在终端205与智能卡或智能卡读取器210之间进行安全通信,在一个实施例中,环境200实现本地链路传输层保护协议,下面还将对此进行详细描述。一些实施例的本地链路传输层保护协议可看成对IETF RFC 2246规定的传输层安全(TLS)协议的改编,其为TCP/IP(传输控制协议/互联网协议)协议族中一个组成部分。具体而言,对于这些实施例来说,支持本地链路传输层保护协议的平台(如笔记本PC)可实现TLS的密码导出和密码过程以及个体密码组的应用模型,其中本地链路传输层保护协议支持个体密码组以保护重要的TLS安全特性。另外,与TLS一样,本地链路传输层保护协议实现如开放式系统互联(OSI)七层模型所定义的传输层中的数据保护,或不同类型模型中具有类似功能的相应层中的数据保护。在这些实施例中,可信智能卡接口基于APDU,在本文中本地链路传输层保护协议也可被称为APDU-TLS或APDU-TLS协议。
为了实现本地链路传输层保护协议,终端205将本地链路传输层保护协议服务器应用程序或Java小程序230(图2的示例性实施例中APDU-TLS服务器应用程序230)存储在数据存储228中或通过机器可读介质(也可用存储器228表示)可对其进行访问。数据存储器228可基于软件或硬件(例如,可信平台模块(TPM)250可用于提供围绕终端205讨论的一些或所有数据存储器)。数据存储器可用于存储支持APDU-TLS所需要的密钥和证书。需要明白的是,在一些实施例中,所示出的在数据存储器和机器可访问介质228中存储的一个或多个组成部分也可存储在TPM 250或图2中未示出的另一数据存储器或机器可访问介质中。
服务器应用程序230与存储在智能卡210上或可被其访问的本地链路传输层保护协议客户机应用程序235(图2的示例性实施例中的APDU-TLS客户机应用程序235)协同工作。客户机应用程序235可存储在数据存储器或机器可访问介质237中,如上面参照终端205所描述的那样,并且可以将其实现为小程序或作为小程序中能够与终端205执行地链路传输层保护协议的库的一部分。
为了在终端205和智能卡210之间进行受保护的通信,首先服务器和客户机应用程序230和235在终端205和智能卡210之间建立本地链路传输层保护协议会话。这包括执行相互认证过程。因此,主机应用程序225可通过本地链路传输层保护协议保护的信道220从智能卡凭证应用程序227访问凭证数据,下面还将对此进行详细描述。
为了支持相互认证过程,在一个实施例中,智能卡210存储终端205可信任的至少一个唯一客户机证书240(例如,由证书授权机构(CA)所颁发),而终端205存储用于建立信任的至少一个根证书245(例如,属于相同的CA)。类似地,终端205存储由智能卡210信任的CA颁发的至少一个唯一服务器证书247,而智能卡存储来自相同CA的至少一个根证书249。在各种情况下,如果有多于一个证书是可用的,则可把第一个证书当成默认值。
只要各种实施例提供智能卡-终端通信链路的认证,这些实施例的本地链路传输层保护或APDU-TLS协议就可支持凭证证书或授权证书。在一些实施例中,终端205和智能卡210由于性能的原因可使用不同的证书格式。例如,服务器证书可基于卡可校验格式,在2003年7月10日的“用作安全签名生成设备的智能卡应用程序接口一第一部分基本要求版本号1.07(the Application Interface for SmartCards Used as Secure Signature Creation Devices-Part 1 BasicRequirements Version 1.07)”中的14.7小节中描述了该格式。这种证书使用RSA签名算法并且用标签长度值(Tag-Length-Values)对数据元素进行编码。
智能卡证书240可基于RFC 2459中规定的X.509v3证书格式的概况(profile)和依据RFC 1421中规定的编码规则的基本64编码PEM文件。各种实施例的智能卡证书240可支持签名算法(例如,RSA)并且至少拥有RSA公钥(可能为1024比特密钥)。因此,相关联的数据结构大小取决于证书数据的内容。与所述一个或多个证书相关联的私钥可存储在智能卡210的保护区域中,任何终端205应用程序或智能卡210上除凭证应用程序227以外的其它应用程序都无法访问该保护区域,所述保护区域包括例如数据存储237的可信存储分区。
ICC 210上的根CA数据结构可用于存储一个或多个根证书249,即用于证书签名验证的CA公钥。根据具体格式,除该文件中存储的公钥外,还可有关于CA的信息。但是,如果使用RSA签名算法和需要至少1024比特RSA公钥,那么,在一些实施例中该文件的长度可大于或等于128字节。
只要使用本地链路传输层保护协议消息来发送和接收证书、执行正确的签名验证并且当发生错误时指示出状态,那么,具体的证书格式细节和签名验证细节就可随不同的实施例而变化。
假设一个简化的PKI(公共密钥基础设施)模型,某些应用可能要求支持多达3级的证书链。PKI模型的细节可由具体配置决定。然而,假设不具有解除能力,这样一来,证书的范围可限制在保护智能卡和/或智能卡读取器210与终端205之间的通信信道。
图3中的高层框图示出了APDU-TLS智能卡310的通用体系结构,可使用智能卡310作为图2的智能卡210。如下面所详细示出和描述的那样,去往/来自终端的APDU首先由APDU-TLS模块335处理,模块335在功能、特征和操作上可对应于图2的APDU安全协议客户机应用程序235。然后,APDU-TLS模块335可解开APDU并将它们传递给凭证应用程序327,凭证应用程序327可对应于图2的凭证应用程序227。图4中给出了一个实施例的基本协议封装模型的示意图。
回到图3,智能卡310上的其它模块可包括,例如,文件管理模块360、密码库365、安全管理模块370和输入/输出(I/O)模块375。依据其它实施例的智能卡和/或智能卡读取器可包括与图3所示出模块不同的一组模块。
回到图2,在运行中,智能卡—终端接口以这样一种方式使用APDU-TLS协议在一个认证过程中,终端实际上是一个服务器,而智能卡实际上是一个客户机。各种实施例的APDU-TLS或本地链路传输层保护协议可被定义为终端205命令和来自智能卡210的相应响应。所有命令由终端205发出并且过程字节(APDU)可用于传输层上的状态。在多数情况下,终端205用“GET RESPONSE(获取响应)”或类似类型的命令从智能卡210中读取返回的数据。
图5中的状态图示出了与一些实施例的本地链路传输层保护协议(在本文中也可称为APDU-TLS)相关联的宏状态和宏事件。
回到图2和图5,智能卡210和终端205之间的APDU-TLS会话有三个主要的状态APDU-TLS INACTIVE(APDU-TLS未激活)505(无APDU-TLS会话)、APDU-TLS HANDSHAKE(APDU-TLS握手)510(APDU-TLS会话启动并进行握手)以及APDU-TLSPROTECTED(APDU-TLS保护)515(握手完成且保护会话已激活)。这些状态不是消息之间单个的协议状态,而是指示终端205上服务器应用程序230和智能卡210之间的一组消息的普通行为的宏状态。相关联的宏事件引起宏状态之间的变迁,从而导致在终端205和智能卡210之间的协议交换,如图5所示。
具体而言,在APDU-TLS非活动状态505中,不存在已启动的或正在进行的APDU-TLS会话。当没有激活使用APDU-TLS模块库235(或图3中335)的应用程序时,这是默认状态。在一种实现方式中,当一个使用APDU-TLS的应用程序被激活时,终端205将用“SELECT DFAPDU-TLS”或其它类型的命令来读配置信息。对包括密码组(Cipher Suite)信息、认证选项、证书格式等的配置信息进行评价后,如果终端205确定要启动APDU-TLS会话,则它选择一个被APDU-TLS激活的应用程序并且触发TLS启动事件520。
图6中是智能卡210和终端205之间的各种个体协议动作的示意图,所述动作响应一个实施例的TLS启动事件,并且引起宏状态变迁到APDU-TLS HANDSHAKE(APDU-TLS握手)状态。
启动包括终端服务器选择APDU-TLS应用程序和开始进行会话握手。对于一个示例性的实施例来说,智能卡可包括用于进行WLAN通信的SIM,如图6所示,这种情况下,终端205可发出“选择WLAN应用程序”或相似类型的命令到智能卡210。智能卡210用给出该命令结果的“STATUS(状态)”进行响应。如果该命令成功,则“GET RESPONSE(获取响应)”或相似类型的命令可用于从智能卡210读取APDU-TLS数据。“READ BINARY”或相似的命令可用于从智能卡210读取配置数据。在该操作后,智能卡210处于“APDU-TLS HANDSHAKE(APDU-TLS握手)”宏状态。
回到图2和图5,“APDU-TLS HANDSHAKE(APDU-TLS握手)”状态510指示正在建立APDU-TLS会话。在APDU-TLS记录协议中,这个状态没有激活的加密操作。在这一状态下,终端205和智能卡210进行APDU-TLS握手过程。这包括图7中示出的若干个协议动作。在图7中,简化了命令/响应符号,使其只表示逻辑消息。例如,虽然“GET RESPONSE”是一条命令,但是由于实际上允许读取一个响应,故将其表示为一个响应。
如图7所示,握手过程涉及各种动作和交换,包括生成服务器和客户机随机数、出示并验证证书、指示任何错误、请求和生成预主机秘密、获取主机秘密和会话密钥、选择修改密码规范以及进行加密。
为了生成随机数,智能卡210应具有生成客户机随机数的良好随机源。在一个实施例中,可信平台模块(TPM)250(图2)可用于生成客户机随机数。另外,由于性能的原因,尽管一些实施例可用软件实现密码操作,但其它一些实施例仍可能需要用硬件实现密码操作,以避免较大延迟。密钥密码块是AES、MD5、SHA和RSA公钥/私钥操作。针对RSA,1024比特公钥大小可用于一些实施例。针对AES,支持256比特是比较好的,但针对各种实施例可支持较小或较大数量的比特。
因此,在终端205和令牌或智能卡210相互认证后,获取密码资料从而对令牌210和终端或平台205上的端点之间的其它流量进行加密。为了进一步保护密钥生成和密钥的存储,在一些实施例中,参照图2,可以使用可信平台模块(TPM)250,即加密协处理器或其它固定令牌。TPM 250在需要时还可用于实现平台绑定。
再次回到图2和图5,如果握手过程/会话成功完成,则APDU-TLS START(APDU-TLS开始)宏事件525引起向APDU-TLSPROTECTED(APDU-TLS保护)宏状态515的变迁,其中激活APDU-TLS会话并进行受保护的数据传输。
图8示出了APDU-TLS PROTECTED(APDU-TLS保护)状态下受保护的应用程序数据交换。在该状态下,还参见图2和图3,可使用TERMINAL WRITE(终端写)或相似类型的命令以对需要发送给智能卡210的应用程序APDU进行写操作。GET RESPONSE(获取响应)或GET BINARY(获取二进制)命令可用于从智能卡210读取应用程序APDU。APDU-TLS模块235(或335)用APDU-TLSHANDSHAKE(APDU-TLS握手)宏状态下所协商的密码规范保护数据。
当处于APDU-TLS PROTECTED STATE(APDU-TLS受保护状态)或APDU-TLS HANDSHAKE(APDU-TLS握手)状态下时,可能发生APDU-TLS STOP EVENT(APDU-TLS停止事件)530或535以说明终端205希望终止APDU-TLS会话。如果在APDU-TLSINACTIVE(APDU-TLS非激活)状态下发生该事件,则在一些实施例中可将其忽略。在一个实施例中,发送特定的APDU以终止APDU-TLS会话(例如,针对一个具体实施例,为ALERT(close_notify))。
在一些实施例中,APDU-TLS RESUME(APDU-TLS重新开始)或类似的事件540还可用于利用新会话密钥对一个会话进行重新协商并且周期性地调用,该周期由终端205策略来设定。
尽管本文所描述的本地链路传输层保护协议在一些实施例中可看成是对TLS协议的改编,但它也可以不与TLS协议兼容并且可能存在明显差异。例如,本地链路传输层保护协议可仅支持IETF RFC3268中围绕加密值计算所描述的TLS密码组的一个子集并且可使用修改的协议消息集。此外,相比TLS协议,在本地链路传输层保护协议中,客户机、而不是服务器可选择密码组。此外,在一些实施例中进行相互认证是强制性的。
因此,上面描述了在凭证和平台之间进行安全通信的一种方法的各种实施例。在前面的描述中,依据具体示例性的实施例对本发明进行了描述。然而,需要认识到的是,在不脱离所附权利要求书的精神和保护范围的情况下,可进行各种修改和变形。例如,尽管在本文中描述了具体示例性的命令,但应该认识到的是,引起执行类似操作的不同命令也可用于其它实施例。因此,说明书和附图应视为说明性的、而非限制性的。
权利要求
1.一种方法,包括接收要在终端与智能卡和智能卡读取器中的一个之间启动本地链路传输层保护协议会话的命令;参与所述终端与所述智能卡和所述智能卡读取器中的一个之间的握手过程,所述握手过程包括相互认证;以及在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个向所述终端提供数据。
2.如权利要求1所述的方法,其中接收要在所述终端与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令包括接收要在个人计算机与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令。
3.如权利要求2所述的方法,其中接收要在所述终端与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令包括接收要在个人计算机与用户识别模块(SIM)、通用SIM(USIM)卡、可拆卸用户识别模块(RUIM)、IP多媒体服务识别模块(ISIM)、无线识别模块(WIM)、Java卡和读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令。
4.如权利要求1所述的方法,其中在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个向所述终端提供数据包括经由可信隧道在无线链路上提供数据。
5.如权利要求4所述的方法,其中在所述无线链路上提供数据包括在蓝牙链路、无线局域网(WLAN)连接和工作在2.4GHz ISM(工业、科技或医学)频带内的无线链路中的一个上提供数据。
6.如权利要求1所述的方法,其中在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个向所述终端提供数据包括在有线链路上提供数据。
7.如权利要求6所述的方法,其中,在所述有线链路上提供数据包括在通用串行总线链路上提供数据。
8.如权利要求1所述的方法,其中参与所述握手过程包括使用TLS(传输层安全)密钥导出过程。
9.一种方法,包括发出要在终端与智能卡和智能卡读取器中的一个之间启动本地链路传输层保护协议会话的命令;参与所述终端与所述智能卡和所述智能卡读取器中的一个之间的握手过程,所述握手过程包括相互认证;以及在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个接收数据。
10.如权利要求9所述的方法,其中如果所述终端可访问的主机应用程序调用了将被所述智能卡210执行的客户机应用程序,则发出要启动本地链路传输层保护协议会话的命令。
11.如权利要求10所述的方法,其中所述主机应用程序是可扩展认证协议用户识别模块(EAP-SIM)应用程序,而所述客户机应用程序是无线局域网-SIM(WLAN-SIM)应用程序。
12.如权利要求9所述的方法,其中发出要在所述终端与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令包括发出要在个人计算机与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令。
13.如权利要求12所述的方法,其中发出要在所述终端与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令包括发出要在个人计算机与用户识别模块(SIM)、通用SIM(USIM)卡、可拆卸用户识别模块(RUIM)、IP多媒体服务识别模块(ISIM)、无线识别模块(WIM)、Java卡和读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令。
14.如权利要求9所述的方法,其中在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个接收数据包括经由可信隧道在无线链路上接收数据。
15.如权利要求14所述的方法,其中在所述无线链路上接收数据包括在蓝牙链路、无线局域网(WLAN)连接和工作在2.4GHz ISM(工业、科技或医学)频带内的无线链路中的一个上接收数据。
16.如权利要求9所述的方法,其中在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个接收数据包括在有线链路上接收数据。
17.如权利要求16所述的方法,其中,在所述有线链路上接收数据包括在通用串行总线链路上接收数据。
18.如权利要求9所述的方法,其中经由可信隧道接收数据包括使用TLS(传输层安全)密码过程。
19.一种装置,包括智能卡和智能卡读取器中的一个;以及存储有本地链路传输层保护协议客户机的数据存储器,所述本地链路传输层保护协议客户机与本地链路传输层保护协议服务器一起实现本地链路传输层保护协议,以便在所述智能卡和所述智能卡读取器中的一个与终端之间建立一条可信隧道。
20.如权利要求19所述的装置,其中所述智能卡和所述智能卡读取器中的一个包括用户识别模块(SIM)、通用SIM(USIM)卡、可拆卸用户识别模块(RUIM)、IP多媒体服务识别模块(ISIM)、无线识别模块(WIM)、Java卡和读取器中的一个。
21.如权利要求20所述的装置,其中所述终端包括个人计算系统和个人数字助理中的一个。
22.如权利要求19所述的装置,其中所述读取器包括移动电话和个人数字助理中的一个。
23.如权利要求19所述的装置,其中所述智能卡和所述智能卡读取器中的一个通过本地链路连接与所述终端相耦合,在所述本地链路连接上提供所述可信隧道,所述本地链路连接是蓝牙、无线局域网(WLAN)、工作在2.4GHz ISM(工业、科技或医学)频带上的连接和通用串行总线(USB)连接中的一个。
24.一种系统,包括存储有本地链路传输层保护协议服务器的数据存储器,所述本地链路传输层保护协议服务器与本地链路传输层保护协议客户机一起实现本地链路传输保护协议,以便在所述系统与智能卡和智能卡读取器中的一个之间建立一个可信隧道;以及用于接纳电池的电池连接,所述电池向所述系统供电。
25.如权利要求24所述的系统,其中所述系统是个人计算系统和个人数字助理中的一个。
26.如权利要求24所述的系统,其中所述智能卡和所述智能卡读取器中的一个通过本地链路连接与所述系统相耦合,在所述本地链路连接上提供所述可信隧道,所述本地链路连接是蓝牙、无线局域网(WLAN)、工作在2.4GHz ISM(工业、科技或医学)频带上的连接和通用串行总线(USB)连接中的一个。
27.如权利要求26所述的系统,还包括可信平台模块(TPM),所述可信平台模块为与所述本地链路传输层保护协议有关的数据提供受保护的存储器。
28.如权利要求24所述的系统,其中所述数据存储器还存储有主机应用程序,所述主机应用程序用来调用将被所述智能卡执行的客户机应用程序,如果调用了所述客户机应用程序,则将调用本地链路传输层保护协议会话。
29.如权利要求28所述的系统,其中所述主机应用程序是可扩展认证协议用户识别模块(EAP-SIM)应用程序,而所述客户机应用程序是无线局域网-SIM(WLAN-SIM)应用程序。
30.一种存储有数据的机器可访问介质,当机器对其访问时使所述机器执行以下操作在终端与智能卡和智能卡读取器中的一个之间启动本地链路传输层保护协议会话;参与所述终端与所述智能卡和所述智能卡读取器中的一个之间的握手过程,所述握手过程包括相互认证;以及在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个接收数据。
31.如权利要求30所述的机器可访问介质,其中如果所述终端可访问的主机应用程序调用了将被所述智能卡210执行的客户机应用程序,则启动本地链路传输层保护协议会话。
32.如权利要求30所述的机器可访问介质,其中在所述终端与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话包括发出要在个人计算机与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的命令。
33.如权利要求32所述的机器可访问介质,其中发出要在所述终端与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令包括发出要在个人计算机与用户识别模块(SIM)、通用SIM(USIM)卡、可拆卸用户识别模块(RUIM)、IP多媒体服务识别模块(ISIM)、无线识别模块(WIM)、Java卡和读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令。
34.如权利要求30所述的机器可访问介质,其中在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个接收数据到所述终端包括经由可信隧道在无线链路上接收数据。
35.如权利要求34所述的机器可访问介质,其中在所述无线链路上接收数据包括在蓝牙链路、无线局域网(WLAN)连接和工作在2.4GHz ISM(工业、科技或医学)频带内的无线链路中的一个上接收数据。
36.如权利要求30所述的机器可访问介质,其中在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个接收数据到所述终端包括在有线链路上接收数据。
37.如权利要求30所述的机器可访问介质,其中经由可信隧道接收数据包括使用TLS(传输层安全)密码过程。
38.一种存储有数据的机器可访问介质,当机器对其访问时使所述机器执行以下操作接收要在终端与智能卡和智能卡读取器中的一个之间启动本地链路传输层保护协议会话的命令;参与所述终端与所述智能卡和所述智能卡读取器中的一个之间的握手过程,所述握手过程包括相互认证;以及在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个向所述终端提供数据。
39.如权利要求38所述的机器可访问介质,其中接收要在所述终端与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令包括接收要在个人计算机与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令。
40.如权利要求39所述的机器可访问介质,其中接收要在所述终端与所述智能卡和所述智能卡读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令包括接收要在个人计算机与用户识别模块(SIM)、通用SIM(USIM)卡、可拆卸用户识别模块(RUIM)、IP多媒体服务识别模块(ISIM)、无线识别模块(WIM)、Java卡和读取器中的一个之间启动所述本地链路传输层保护协议会话的所述命令。
41.如权利要求38所述的机器可访问介质,其中在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个向所述终端提供数据包括经由可信隧道在无线链路上提供数据。
42.如权利要求38所述的机器可访问介质,其中在所述握手过程成功完成后经由可信隧道从所述智能卡和所述智能卡读取器中的一个向所述终端提供数据包括在有线链路上提供数据。
43.如权利要求38所述的机器可访问介质,其中参与所述握手过程包括使用TLS(传输层安全)密钥导出过程。
全文摘要
一种用于在终端与智能卡和智能卡读取器中的一个之间进行安全通信的方法。在所述智能卡或智能卡读取器一端,接收要在终端与智能卡和智能卡读取器中的一个之间启动本地链路传输层保护协议会话的命令。接着,响应所述命令,所述智能卡或智能卡读取器参与所述终端与所述智能卡和所述智能卡读取器中的一个之间的握手过程。所述握手过程包括相互认证。然后,在握手过程成功完成后,经由可信隧道从所述智能卡和所述智能卡读取器中的一个向所述终端提供数据。
文档编号H04L29/06GK101031939SQ200580033412
公开日2007年9月5日 申请日期2005年10月13日 优先权日2004年10月19日
发明者塞利姆·艾斯, 简·达舍夫斯凯, 阿沛·达马德卡里, 本杰明·默特萨, 乔斯·普森库拉姆, 穆杜拉·耶拉曼基 申请人:英特尔公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1