JP4869259B2 - System and method for data communication allowing a slave device to become a network peer - Google Patents

Abstract

A system and method for peer-to-peer communication between a slave device and network resources wherein the slave device, for example, a smart card, communicates using a protocol designed to allow the smart card to communicate over a half-duplex serial communications link while appearing to applications and network nodes as being a full-fledged network node in a manner that conserves power so as to be suitable for deployment on small portable devices.

Description

  The present invention claims priority from US Provisional Application No. 60 / 65,291, filed on Feb. 11, 2005, in accordance with 35 USC 119 (35 USC 119). This provisional application is incorporated herein by reference in its entirety.

  No. 10 of copending US application entitled “Secure Networking Using a Resource-Constrained Device” filed on May 19, 2004, assigned to the assignee of the present invention and incorporated herein by reference. No. 848738 describes a system and method for providing communication between resource-constrained devices that communicate using a half-duplex communication channel and remote nodes connected to a network. . The present invention provides improvements to the invention described in the above specification.

  A co-pending US patent application entitled “Communications of UICC in mobile devices using Internet Protocol” filed on September 23, 2005, assigned to the assignee of the present invention and incorporated herein by reference. In 11/234777, systems and methods are described that allow a UICC in a mobile device to operate as a network peer.

  “Smart Card Control of Terminal and Network” filed on Nov. 30, 2000, which is a continuation of U.S. Patent Application No. 09/107033, filed on June 29, 1998, currently US Pat. No. 6,157,966. In co-pending U.S. patent application Ser. No. 09/727174 entitled “Resources”, a resource-constrained device is communicating on a half-duplex communication channel, but the resource-constrained device is still A system and method for asynchronous communication with a host device that enables it to act as a peer with respect to it has been described.

  The present invention relates to the operation of network-based electronic devices, and more particularly to a system and method for allowing a device that is conventionally a slave to become a network peer.

  In a new information era, computing is becoming popular. Until now, machines of the class that were completely “dumb” machines have gained a certain level of “intelligence”. As this trend continues, the machines are also expected to a higher level. For example, previous generation machines were not expected to have any computing power, but subsequent generations have gained some degree of computerization. A further step in this evolution is to connect the machine to the network. However, often computing power and memory size can be very limited because of physical size constraints or because computing power and data storage are not the main functions of a machine. These constraints have a significant impact on the ability of such resource-constrained devices to interact with other nodes on the network.

  An example of such a resource-constrained device is a smart card. A smart card is simply a plastic card that contains an integrated circuit with some memory and a microprocessor. Usually, the memory is limited to 6K bytes of RAM. Smart card RAM is expected to grow by several kilobytes over the next few years. However, the memory size is very likely to continue to be an obstacle for smart card applications. Most smart cards have an 8-bit microprocessor.

  The communications infrastructure introduces another resource constraint for smart cards and similar devices. Smart cards do not have the highest speed USB communication and lack a full-duplex serial interface. Currently, smart cards use an ISO-7816 interface that operates in half duplex.

  There are other devices that have similar resource limits. These devices include USB dongles (such as iKey devices sold by SafeNet, Inc., Bell Camp, Maryland), or SD cards, or secure integrated circuit chips that are soldered directly to a PC motherboard.

  In this specification, devices having similar resource limitations in common, for example, RAM limited to less than 64K, are referred to as “resource-constrained devices”. Resource constrained devices include smart cards, USB dongles, SD cards, and secure integrated circuit chips attached directly to a PC motherboard. Furthermore, the term resource constrained device shall include any other device having resource constraints similar to those listed above. For clarity, the present invention is described herein primarily in the context of smart cards. This should not be construed as limiting the scope or applicability of the present invention. This is because the present invention is applicable to other resource-constrained devices as well.

  Smart cards have been used in terminal devices or hosts, which can be smart card readers or computers with cell phones or other devices. When a smart card is connected to a computer, the host application cannot communicate with the smart card using a standard mainstream network interface. Specific hardware and software in the form of smart card reader device drivers and middleware applications are required to access card services.

  Patent application Ser. No. 10/848738, assigned to the assignee of the present invention, entitled “Secure Networking a Resource Constraint Device”, uses a half-duplex serial command / response communication protocol, and Describes a new protocol called Peer I / O that allows other resource-constrained devices to handle full-duplex peer-to-peer communications (hereinafter “738” application). Thus, such devices that introduce peer I / O can join the network as network peers.

  It would be useful to have a generally applicable system and method to allow devices communicating using a half-duplex serial command / response communication protocol to handle asynchronous full-duplex peer-to-peer communication. I will.

  There is a current trend to make electronic communication devices portable, compact, and wireless that will probably continue. One challenge arising from this trend is that by being wireless, the device must have its own power source, usually a battery. Since the battery is a resource that tapers until the device is reconnected to a wired power source, the duration of available power, or simply battery life, is a major issue. The selling factor for portable devices is the size of the device. Of course, the smaller the device, the smaller the battery and thus the shorter the battery life.

  One very common, resource-constrained device is the SIM module for mobile phones. Over the last few years, mobile phones have been given many new features and functions. Patent application 11 / 234,77, assigned to the assignee of the present invention, entitled "Communications of UICC in mobile devices using Internet Protocols", is a SIM card running a web server on a SIM card, for example. By doing so, application destinations that can operate as network peers are described. Power consumption, and battery life, the consequences associated with power consumption, are very important in the context of mobile phones. Thus, electronic devices that communicate using half-duplex serial commands / responses can handle asynchronous full-duplex peer-to-peer communications while conserving power and thereby extending the battery life of mobile devices. It would be desirable to have a system and method for

  From the above, full-duplex peer-to-peer communication by a network-connected resource-constrained device that communicates using a half-duplex serial command / response communication link is performed by the resource-constrained device. It will be apparent that there is still a need for improved systems and methods that allow for the power consumption imposed on mobile devices to which the device is connected.

  In a preferred embodiment, the present invention provides a full-fledged application and network node set in a manner that saves power so that slave devices, eg, smart cards, are suitable for deployment on small portable devices. Between a slave device and a network resource that communicate using a protocol designed to allow smart cards to communicate over a half-duplex serial communication link while appearing to be a secure network node Systems and methods for peer-to-peer communication are provided.

  Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

  In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that the various embodiments of the invention are different but not necessarily mutually exclusive. For example, certain features, structures, or characteristics described herein in connection with one embodiment may be practiced within the scope of other embodiments without departing from the spirit and scope of the invention. May be. Further, it is to be understood that the position or configuration of individual elements within the scope of each disclosed embodiment can be changed without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims as well as the equivalents found in the claims as appropriate Defined only by full range. In the drawings, like numerals refer to the same or similar functionality in all of the several views.

  As shown in the drawings for purposes of illustration, the present invention is in a network-enabled electronic device, eg, a network smart card, with the ability to provide peer-to-peer communication to a network-enabled electronic device while minimizing power consumption. To be implemented.

  FIG. 1 is a schematic diagram illustrating an operating environment in which a networked electronic device according to the present invention can be installed.

  In one example, the network compatible electronic device 101 is a network smart card implemented in the handset 103. The handset 103 can be a mobile phone having normal mobile phone equipment such as a keyboard 105, a display 107, a microphone 109, and a speaker 111. In alternative embodiments, the handset 103 can be a personal digital assistant, or any other mobile device that uses a SIM card. The handset 103 also includes an electronic circuit (not shown) that includes a central processing unit and a memory. In addition, various smart mobile devices are available, such as web-enabled phones, smart phones, PDAs, handheld PCs, and tablet PCs. Many smart phones and PDAs have both a cell phone function and a PDA function. Popular operating systems for smart mobile devices include Symbian (R), Palm (R) OS, and Microsoft (R) Smartphone. The invention described herein is applicable to such a device if it has a SIM device that is a network smart card 101.

  The electronic circuitry provides the handset 103 with a communication function with the wireless network 117 via a wireless link to the wireless telephone antenna 119. The microprocessor also provides some of the control functions of the handset 103, such as managing the operation of the handset 103 and managing the communication protocol used to communicate with the wireless network 117. The network smart card 101 is connected to an electronic circuit so as to allow communication between the network smart card 101 and the handset 193.

  The wireless network 117 consists of a complex communication infrastructure for providing connections to other stations, for example to other mobile stations or ground-based telephone systems. One such station can be an Internet gateway 121 that provides wireless network 117 access to the Internet 125. As is generally known, a large number of computers are connected via the Internet. In the scenario presented herein, a user of a handset, eg, a mobile phone or PDA, uses a handset 103 or some other computer connected to the Internet 125 using the infrastructure shown in FIG. To communicate with the network smart card 101. Some aspect of this communication uses direct communication between the network smart card 101 and the remote entity 127 for the purpose of communicating some information stored on the network smart card 101 to the remote entity 127, for example.

  Another example of a networked electronic device 101 'is a network smart card that has a credit card form factor and is connected to the Internet 125 via a host computer 103'.

  The network smart card 101 or 101 'is a smart card that can operate as an autonomous Internet node. A network smart card is a co-pending patent application 10/848738 filed May 19, 2004, “SECURE NETWORKING USING A RESOURCE-CONSTRAINED DEVICE,” filed May 19, 2004, the entire disclosure of which is incorporated herein by reference. Described in. The network smart card 101 implements the Internet protocol (TCP / IP) and security protocol (SSL / TLS) embedded in the card and can implement other communication protocols described later in this specification. The network smart card 101 can establish and maintain a secure internet connection to other internet nodes. The network smart card 101 does not rely on a proxy on the host to enable Internet communication. Furthermore, the network smart card 101 does not require a local or remote internet client or internet server to be modified to communicate with the smart card.

  The present invention is also applicable to use in other devices, including other network-capable resource-constrained devices, and is not necessarily limited to resource-constrained devices in use. For example, a network-enabled electronic device according to the present invention can be a computer 101 ″. As used herein, the term network-enabled device refers to any electronic device that is connected to and can electronically communicate with other electronic devices over a network. Similarly, reference numeral 101 is used to refer to any such device, rather than specifically to any one such device.

  The networked electronic device can be a network smart card, eg, smart card 101 '. As described in copending patent application Ser. No. 10/848738, filed May 19, 2004, “SECURE NETWORKING USING A RESOURCE-CONSTRAINED DEVICE,” filed May 19, 2004, the entire disclosure of which is incorporated herein by reference. A network smart card combines the functions of a conventional smart card and the ability to operate as an autonomous network node by implementing a communication protocol stack used for network communication. When the electronic device 101 connected to the network is connected to the network via the host computer 103 ′, the host computer 103 ′ may become an attack computer, for example, as a reflector or when some malware is installed. .

  FIG. 2 is a schematic diagram of an exemplary architecture of the hardware of a networked electronic device 101 that can be used in conjunction with the present invention. 2, the network-connected electronic device 101 has a central processing unit 203, a ROM (read only memory) 205, a RAM (random access memory) 207, an NVM (nonvolatile memory) 209, and inputs. A communication interface 211 for receiving and sending output directly to a computer network to which the networked electronic device 101 is connected, eg, the Internet, or via an intermediate device such as the host computer 103 ′; Have. The various components described above are connected to each other by a bus 213, for example. In one embodiment of the invention, a communication module 321 (introduced in FIG. 3 below and described later in connection with FIG. 3 and other figures herein), and Another software module group described later is stored in the ROM 205 on the resource-constrained device 101. In alternative embodiments, software modules stored in ROM 205 are stored in flash memory or other types of non-volatile memory. For illustrative purposes, the present invention will be described using a ROM example. However, it should not be construed as a limitation on the scope of the present invention, and flash memory and other types of non-volatile memory can be substituted instead whenever a ROM is used. is there.

  The ROM 205 also includes some type of operating system, such as a Java virtual machine. As an alternative, the communication module 321 is part of the operating system. During operation, the CPU 203 operates in accordance with instructions in various software modules stored in the ROM 205 or NVM 209.

  For this reason, according to the present invention, the CPU 203 operates according to instructions in the communication module 321 and executes various operations of the communication module 321 described later in this specification.

  FIG. 3 is a schematic diagram of the software architecture for the resource-constrained device 301 and host computer 303. In the context of FIGS. 1 and 2, the resource-constrained device 301 can be a SIM card 101 or a network smart card 101 ′, and the handset 303 can be a handset 103 or a host computer 103 ′. It is.

  The host computer 303 is loaded with several network applications 305a, 305b, and 305c. (Note that, in the case of the handset 103, the handset physical architecture is substantially similar to the architecture of the computer. For this reason, the handset 103 has a memory and a processor. The memory can be RAM, ROM, The memory can include a group of software modules that control the behavior of the processor, etc. Thus, the various software modules shown in FIG. Stored in some non-volatile memory and loaded into RAM while executing, from which software module instructions control the behavior of the processor and cause the mobile device to do a number of things, for example Established network connection That.) Examples of such applications include Web browsers, and network contact list application. In the case of a web browser, the application 305a accesses the resource-constrained device 301 or, more precisely, a web server that runs on the resource-constrained device 301, eg, a SIM card network application 307a. Can be used to communicate with.

  The host computer 303 and the resource-constrained device 301 communicate via several layers of communication protocols. In one embodiment, the layers include several communication software modules, eg, a TCP / IP module 317 for handling communication at the TCP / IP level on the host computer 303, as well as a correspondence on the resource-constrained device 301. An I / O server module 315 on the host computer 303 for communicating with a TCP / IP module 327, a PPP module 318 and 329 for handling communication at the PPP level, and a peer I / O protocol, and resource constraints It can be represented by a corresponding peer I / O client module 325 on a device 301. The operations of the peer I / O client module 325 and the peer I / O server module 315 are described in more detail later in this document.

  Also, the resource-constrained device 301 and the host computer 303 are connected as a hardware layer, for example, via USB connection or wireless connection, and a hardware communication module for managing hardware level communication accordingly 318 and 319.

  The host computer 303 can establish communication with an external data network and can support several applications 305a-c. The application program on the host computer uses the communication module 311 to establish a connection to the outside of the network and communicate with the applications 307a-c on the resource-constrained device 301.

  Communication between the resource-constrained device 301 and the network via the host computer 303 is “SECURE NETWORKING USING A RESOURCE-CONSTRATED DEVICE” filed May 19, 2004, which is incorporated herein by reference. Is described in more detail in co-pending patent application Ser. No. 10/848738, cited above. Virtual serial port 313 implements a serial port interface defined by the operating system of handset 303. Communication between network SIM cards (also known as network UICC cards) is described in co-pending patent application Ser. No. 11 / 234,777, “COMMUNICATIONS OF, filed Sep. 23, 2005, incorporated herein by reference. This is described in more detail in “UICC IN MOBILE DEVICES USING INTERNET PROTOCOLS”.

  A peer I / O implementation exists on both the host 303 and the device 301. On the host side, peer I / O provides a service for transferring messages between device 301 and network 117. In this specification, this service module is referred to as a peer I / O server 315. Device 301 has a peer I / O client 325 located above a low-level half-duplex serial communication protocol 318 operating in command / response mode and below a full-duplex protocol such as PPP 329. Including. Such full-duplex communication is asynchronous because both ends of the communication channel can be transmitted at any time without synchronization or timing adjustment with the other end. The peer I / O protocol is independent of the higher level protocol it transmits. From the upper layer protocol perspective, peer I / O can transmit messages back and forth in both directions. For example, peer I / O can be used to transmit PPP frames, Ethernet frames, or IP datagrams. That is, data communication between the resource-constrained device 301 and the host 303 is performed via a half-duplex serial command / response link, both on the resource-constrained device 301 and on the host 303. Even on other network nodes that may be communicating with resource-constrained device 301, it is transparent to higher level applications and communication protocols.

  When a computer on the network (or simply referred to as a “network”) sends a message to the device, the peer I / O server 315 sends one or more commands of a command / response communication protocol containing the message to the device 301. To forward the message. The peer I / O server 315 periodically polls the device 301 to allow the device 301 to send a message to the network 117 whenever it needs to send it. If the device has a message, the peer I / O server 315 issues one or more commands that acquire the device's message and forward the message to the network. The operation of devices 301 and 303 performing communications over the half-duplex serial command / response link connecting these devices is controlled by peer I / O server 315 and peer I / O client 325. In one embodiment of the invention, this behavior is implemented according to a finite state machine on the resource-constrained device 301 and on the host device 303. The peer I / O finite state machine allows communication to be performed using any length of high-level message without using an explicit fragmentation-assembly mechanism.

(Peer I / O protocol format)
The peer I / O protocol defines three commands: Put Packet, Get Packet, and Poll. The Put Packet command transmits data from the host to the device. The Get Packet command acquires data from the device to the host. The Poll command is used by the host to check with the device whether the device has data to send. The implementation of the above commands is protocol dependent. If feasible, the Poll command can be implemented as a Put Packet command without data. In that case, the peer I / O protocol requires only two commands, Put Packet and Get Packet.

ただし、Ｌｅｎｇｔｈは、ホストからデバイスに送信されるべきデータの長さである。ホストからＰｕｔ Ｐａｃｋｅｔコマンドを受信した後、デバイスは、データを獲得し、ステータスを戻す。 Peer I / O command types can be represented by 1 byte, or 2 bits, or even 1 bit, depending on the underlying protocol. The Put Packet command usually has the following format.

Here, Length is the length of data to be transmitted from the host to the device. After receiving the Put Packet command from the host, the device acquires data and returns a status.

The Get Packet command typically has the following format, where Length is the length of data to be acquired from the device to the host.

  After receiving a Get Packet command from the host, the device sends the requested length of data to the host and then sends a status.

  The Poll command usually does not require parameters. After receiving the Poll command from the host, the device sends a status.

The status returned from the device to the host can represent several things, including: That is,
It has length n data to be transmitted.
There is no data to be sent.
There is no data to be sent and set the polling interval. The polling interval can be infinite, which means "Don't poll, I'm waiting for data".

  Underlying protocols typically limit the length of data within a packet. For example, some protocol limits the data to 256 bytes. The peer I / O protocol observes the limitations of the underlying protocol. The peer I / O protocol allows larger packets to be sent and received by issuing multiple put and get commands as needed. The peer I / O protocol assumes that the upper layer protocol knows the boundaries of the peer I / O protocol packet.

(Operation of peer I / O protocol)
This section describes some normal operations of the peer I / O protocol. When the network sends data to the device, the peer I / O server 315 issues a Put Packet command to the device.

If a device wants to send data to the network, it must wait for the opportunity. The peer I / O server 315 periodically polls the device and gives the device an opportunity to transmit. The server issues a POLL command.

  After receiving a command from the peer I / O server 315, if the device has no data to send, the device sends a status indicating that. If the device has data to send, the device sends a “has data” status and the length of the data that the device intends to send.

When receiving a status indicating that the device has data to be transmitted, the peer I / O server 315 issues a Get Packet command.

The device responds with a response containing data.

  If the Status indicates additional data to be transmitted, the peer I / O server 315 can issue another Get Packet command.

(Suppressed polling)
A peer I / O server 315 at the host periodically polls the device to see if it has data to send. This polling is suppressed by a polling interval that can be infinite. Such suppressed polling reduces the power consumption that will occur if the device 301 is constantly polled by the host 303.

  Peer I / O defines a new return status that allows a polling interval to be specified. The default polling interval is “as often as possible”. The interval can be specified in seconds, minutes, or hours. The peer I / O server 315 performs polling as close to the polling interval as possible. Also, the polling interval can be infinite. When the device is waiting to receive data, it can specify an infinite polling interval. In that case, the peer I / O server 315 does not poll the device and contacts the device only if data is available for the device. For example, if the device is a web server, the device can set the polling interval to infinity when waiting for a client connection. This new addition to peer I / O is related to mobile applications, for example, the host is a small mobile device powered by a battery and the device consumes the power supplied by the host. In case it is very important.

  As an example, the return status can be expressed in two octets. The most significant 4 bits represent “having data” or “no data”. For the “having data” case, the remaining bits can represent the length of the data. For the “no data” case, all remaining bits are 0, meaning “use current polling interval”, which can be the default poll. If all remaining bits are 1, this means "don't poll". Otherwise, the next two bits represent a unit of polling interval such as seconds, minutes or hours. The remaining 10 bits represent the polling interval.

For example, the following figure shows the return status for a case with no data.

The following figure shows the return status for the case with data.

  The operations of peer I / O server 315 and peer I / O client 325 are controlled by two finite state machines, respectively.

  FIG. 9 is a schematic diagram of a finite state machine 901 that controls the behavior of the peer I / O server 315.

The FSM (Finite State Machine) 901 has the following five statuses. That is,
Initial state 902,
Polling 903,
905 acquired from the client,
Put data 909 on the client and check 907 for data.

There are four events: That is,
Four types of return status from clients, ie
The client has data. (Cd)
The client has no data and does not change the polling interval. (Cnd)
The client changes the polling interval without data. (Cnd + p)
The client has no data and does not poll. (Cnd + np)
Two results of checking the network. That is,
The network has no data. (Nnd)
The network has data. (Nd)
There are four actions: That is,
Get packet from client.
Put the packet on the client.
Get a packet from the network.
Put a packet on the network.

  Peer I / O server 315 begins by polling peer I / O client 325. In response to that polling, client 325 determines whether client 325 has data transmission and a polling interval that peer I / O server 315 should wait before retransmitting to peer I / O client 325. Can show.

  Whenever the peer I / O client 325 returns a status (cd), it is a transition 401, which is an indication that the client 325 has data to send. In response to the instruction, the peer I / O server 315 acquires data from the client 325 and transfers the data to the network 117. The server 325 continues to acquire data from the client 315 by issuing a Get_Packet action (state 905), and transfers data to the network as long as the client 315 returns status cd (transition 403).

  When the client returns a value cnd or a status indicating that it has no data to send by returning ready to receive, the peer I / O server 315 examines the network (state Transition to 907 407). If the network has data, peer I / O server 315 obtains data from the network and forwards the data to client 325 (transition 409 to state 909). If the network does not have data (nnd), the peer I / O server 315 may or may not poll the client 325 depending on the polling interval setting. For example, if the polling interval is set (pintv) and the time elapsed since the previous transmission to the client 325 has reached the polling interval (timeout), the peer I / O server 315 sends the client 325 Polling is performed (transition 411 to state 903), otherwise, if the polling interval has not been reached (timeout), the server 315 remains in the “check network” state 907 (transition 413).

  FIG. 5 is a schematic diagram of a finite state machine 501 that controls the behavior of the peer I / O client 325.

The peer I / O client state machine has four states: That is,
Initial state, state 503
Wait for upper layer command (read or write), state 505
Write ready, waiting for peer I / O server, state 507
Read ready, waiting for peer I / O server, status 509
There are five events: That is,
Read command from upper layer Write command from upper layer Poll command from peer I / O server 315 Put command from peer I / O server 315 Get command from peer I / O server 315 The following four actions exist To do. That is,
The status “client has data” (cd) is sent to the peer I / O server 315. The status “client has no data” (cnd) is sent to the peer I / O server 315. Do not change the polling interval. (Cnd)
The client changes the polling interval without data. (Cnd + p)
The client has no data and does not poll. (Cnd + np)
Data is transmitted from the peer I / O server 315 to the peer I / O server 315 that acquires data.

  Device 301 operates peer I / O client 325, which starts at initial state 503. An upper layer, for example, applications 307a-c communicating via the TCP / IP module 327 can request to write or read. For example, if the device 301 wants to initiate a connection to the network, the application 307 on the device 301 sends an initial message to initiate the connection (the peer I / O protocol initiates the connection Does not depend on whether it is a device or a host). When the upper layer issues a write command, the peer I / O client 325 leaves the “initial” state 503 and moves to the “write ready” state 507 (transition 511). While in the “write ready” state 507, the peer I / O client 325 waits for a message from the peer I / O server 315. As previously described herein, server 315 begins by polling client 325. When the server polls and the client 325 is in the write ready state 507, the client 325 sends a status cd along with the number of bytes to be transmitted (transition 513) and remains in the “write ready” state 507. When the server 315 issues a Get Packet command, the client 325 transmits data, moves to the “upper wait” state 505, and the client 325 waits for an upper layer command (transition 514).

  When the upper layer issues “write” while the client 325 is in the “waiting for upper” state 505, the client 325 sends a status cd to the peer I / O server 315 and enters the “write ready” state 507. Transition (transition 516). On the other hand, if the upper layer issues “read”, the client 325 sends the status cnd to the peer I / O server 315 and moves to the “read ready” state 509 (transition 517). In addition, when the client 325 receives a “read” command from an upper layer while the client 325 is in the “initial” state 503, the client 325 can transition from the “initial” state 503 to the “read ready” state 509. (Transition 521). In a “read ready” state 509, the client 325 waits for a peer I / O server 315 command. When server 315 polls, client 325 sends another cnd and stays in “read ready” state 509 (transition 519). If the server 315 issues a Put Packet command, the client 325 acquires data and moves to the “waiting for higher rank” state 505 (transition 515).

(Application)
The peer I / O protocol has many applications. The first example is connecting a network smart card to the Internet via a host computer.

  A smart card is a small card that includes a microprocessor chip. ISO defines two form factors for smart cards: a credit card shaped card and a SIM (Subscriber Identification Module) card. Smart cards are secure, portable, and not susceptible to unauthorized changes. Smart cards have been served for security purposes in a wide variety of applications, including mobile communications (SIM cards in cell phones), banking transactions, physical access restrictions, network access restrictions, traffic, digital IDs, and the like. Unfortunately, smart card communication standards do not match mainstream computing communication standards, which limited the success of smart cards.

  The current smart card standard ISO 7816 (ISO 14443 for contactless smart cards) specifies a half-duplex serial command / response communication protocol, whereas standard Internet protocols such as PPP, IP, and TCP are all Operates in dual peer-to-peer mode. By applying peer I / O, current smart cards that are compliant with ISO 7816 (or ISO 14443) can become Internet nodes. This section describes the implementation of peer I / O using ISO 7816 commands.

  FIG. 6 is a first alternative diagram for connecting an infrastructureless network smart card 301 according to the present invention to a network 117. The infrastructureless network smart card 301 is connected to a reader 302 connected to the host computer 303. The computer 303 is connected to the network 117. The computer 303 serves as a router for routing Internet communications to and from the card 301. The computer 303 has a first IP address for connection to the network 117 and a second IP address for connection to the infrastructureless network smart card 301. There is a third IP address associated with the infrastructureless network smart card 301. The third IP address can be assigned to the card 301 or can be dynamically allocated.

  The computer 303 has a RAS (Remote Access Server) that provides Internet services to other computer groups connected to the computer. If the smart card 301 has full-duplex serial I / O, just like any other full-duplex serial device, the smart card with TCP / IP / PPP will load any additional software on the computer 303. Without it, an internet connection can also be established via RAS. In reality, the smart card standard specifies half-duplex serial I / O. In addition to full-duplex versus half-duplex issues, the Internet protocol is peer-to-peer, which means that nodes can communicate at will, whereas the ISO 7816 and ISO 14443 protocols are smart cards issued by terminal equipment. Specifies a command / response action that only responds to the command issued. The peer I / O protocol implemented in accordance with the present invention solves both of the above protocol mismatch problems.

  The peer I / O implementation according to the present invention exists as a cooperating communication module on the host computer 303 (or reader 302) and in the smart card 301. The host computer (or reader) includes a peer I / O server 315 that provides a service for transferring messages between the card and a RAS (Remote Access Server) on the host. The card includes a peer I / O client located above ISO 7816 and below other protocols such as PPP.

  When the RAS sends a message to the card, the peer I / O server 315 forwards the message by sending one or more APDU commands containing the message to the card. In order to allow the card to send messages to the RAS, the peer I / O server 315 polls the card periodically according to a polling interval.

  FIG. 7 is a high-level schematic diagram of a communication protocol stack, a host computer 303, and a network smart card 301 that implement a peer I / O protocol.

  In embodiments of the invention that include the link layer protocol outlined herein as peer I / O, the peer I / O module resides in both the host computer 303 (or reader 302) and the card 301. To do. The peer I / O server module 315, which is a protocol stack on the host PC side 303, implements the peer I / O protocol layer, and sends messages between the card 301 and the RAS (Remote Access Server) 701 on the host computer 303. Provide a service to transfer. On the smart card 301 side, the protocol stack includes a peer I / O protocol layer 325 located above the APDU 807 and located below other protocols, such as PPP 329. The APDU provides communication between the host 303 and the card 301. The peer I / O protocol does not depend on the internet protocol transmitted by the peer I / O protocol. Viewed from higher layer protocols, peer I / O can transmit messages back and forth in both directions. For example, peer I / O can be used to transmit PPP frames, or Ethernet frames, or IP datagrams. Peer I / O uses APDUs to transmit messages such as PPP frames, Ethernet frames, or IP datagrams. The following description of peer I / O uses RAS and PPP as examples. In that case, the peer I / O transmits the PPP frame using the APDU.

  When the RAS sends a message to the card 301, the peer I / O server 315 forwards the message by sending one or more APDU commands containing the message to the card 301. In order to allow the card 301 to send messages to the RAS, the peer I / O server 315 polls the card 301 periodically as described earlier in this specification. The finite state machine, described in more detail below, of peer I / O server 315 and peer I / O client 325 forwards messages of any length without using an explicit fragmentation-assembly mechanism. Define the mechanism.

(Peer I / O protocol format)
The following defines one implementation of peer I / O built on the ISO 7816 communication protocol. Peer I / O implementations are not limited to the following defined classes, instructions, and status word sets. The peer I / O protocol defines a new ISO 7816 class, CLA = 0x12, for the peer I / O protocol (ISO 7816-4 reserves 0x10-0x7F CLA numbers for future use. 0x10 is used). For this peer I / O class, three instructions are defined: POLL, GET_PACKET, and PUT_PACKET. Peer I / O server 315 uses POLL to poll the card to see if it wants to send something, uses GET_PACKET to obtain data from the card, and PUT_PACKET To send data to the card. The peer I / O protocol does not have its own protocol data unit. The peer I / O protocol uses APDUs directly.

The peer I / O command APDU has the following format. That is,

The instruction INS can be one of the following: That is,
POLL (0xE8) Length = 1, Data is an arbitrary 1 byte.
PUT_PACKET (0xEA) Length is the number of bytes of Data transmitted to the card.
GET_PACKET (0xEC) Length is the number of Data bytes received from the card.

  Length is 1 byte, and therefore the maximum data length is 256 bytes. Note that the POLL command sends any one byte. This is done to avoid ISO 7816 Case I commands where no ACK is sent by the card and some readers do not work well.

The response APDU has the following format: That is,

ACK represents an acknowledgment from the card regarding receipt of a command from peer I / O server 315. ACK is the INC code of the received command. The status of the process on the card side is expressed by SW1 and SW2 in the response APDU. For all three peer I / O instructions, the response status can be as follows: That is,
READY-WRITExx (eg, 6Cxx) xx represents the number of bytes that the card is ready to transmit.
NO-DATA (e.g. 9000) Card is ready to receive.
The 9xxx card sets the polling interval.

  The reason for using 6Cxx for normal status is as follows. The host-side IOP API does not export the status of APDU commands. Therefore, 6Cxx is used so that the peer I / O server 315 catches 6Cxx as an exception.

(Peer I / O operation)
When the RAS sends data to the card, the peer I / O server 315 issues a PUT_PACKET command to the card. APDU contains data.

If the card wants to send data to the RAS, the card must wait for the opportunity. The peer I / O server 315 periodically polls to give the card an opportunity to transmit. The server issues a POLL command.

After receiving the command APDU from the peer I / O server 315, the card first responds with an ACK. If the card has no data to send, the card sets SW1 SW2 to NO-DATA (eg, 900).

If the card has data to send, the card sets SW1 SW2 as 6Cxx, where xx is the length of the data that the card intends to send.

When peer I / O server 315 receives a response with status READY-WRITE (6Cxx), peer I / O server 315 issues a GET_PACKET command with Length = xx before issuing any other command. Issue.

The card responds with a response APDU containing data.

  If SW1 SW2 = 6Cxx, the peer I / O server 315 can issue another GET_PACKET command.

(Implementation on smart card)
8 and 9 are schematic diagrams of two alternative implementations of a peer-to-peer communication system according to the present invention on a smart card system.

  FIG. 8 is a schematic diagram of components for performing communication between a smart card and a network where the smart card communicates to a host computer using a serial connection with half-duplex serial I / O. The smart card 301 is connected to the host computer 303 via the reader 302. The driver of the reader implements the peer I / O server 315. Along with the serial port driver 803, the composite driver behaves as a (virtual) serial port when viewed from the host computer 303. A normal RAS connection to the virtual serial port allows a network connection to the smart card 301.

  Peer I / O server 315 can also be implemented with hardware in a smart card reader. FIG. 9 illustrates communication between a smart card and a network where the smart card communicates to the hardware interface device via a half-duplex serial connection and the interface communicates to the host computer using a full-duplex connection. It is the schematic of the component for implementing. The reader 302 is connected to the host computer 303 via a serial connection or a USB connection. (In USB connection, USB / serial conversion is required in the reader and the host computer.) In this case as well, network connection to the smart card 301 is possible by normal RAS connection to the serial port.

(MMC (MultiMediaCard))
In another alternative embodiment, the invention described herein is used to connect an MMC (MultiMediaCard) to a network. In that embodiment, the MMC card has approximately the same role as the network smart card 201 described herein.

  MMC (MultiMediaCard) is a small (24 mm x 32 mm or 18 mm x 1.4 mm), removable, solid for mobile applications such as cell phones, digital cameras, MP-3 music players, and PDAs It is a state memory card. The storage capacity of the MMC is up to 1 gigabyte of data. A high-speed MMC can transfer data up to 52 megabits per second. MMC uses flash technology for read / write applications and ROM technology or flash technology for read-only applications.

  The MMC has a 7-pin serial interface with 3 communication lines (command, clock and data) and 4 supply lines. MMC initialization and MMC data transfer are based on the MMC bus protocol. Each message uses one of three tokens: command, response, and data. A command token sent from the host to one or more cards initiates an operation. The response token is transmitted from the addressed card or card group to the host. Data tokens can go in either direction. All bits on the data line and on the command line are transferred synchronously using a clock.

  Secure MMC (Secure MultiMediaCard) adds smart card security functionality to MMC for content protection and e-commerce. The secure MMC has a module that is not susceptible to unauthorized modification for secure storage and performs encryption and authentication within the card. For example, Infineon Technologies uses smart card hardware technology in secure MMC. Secure MMC is fully compatible with standard MMC.

  Recently, the MultiMediaCard Association (www.mmca.org) has formed a working group to standardize the next generation secure MMC (Secure MultiMediaCard) (www.mmca.org/press/SecurityFinal.pdf). New specifications 2.0 defines an extension to the MMC standard protocol that creates a communication interface for incorporating smart card technology. This allows the MMC to provide smart card security functions such as encryption and authentication. The extended MMC command set allows the MMC interface to carry standard smart card ISO-7816 APDUs.

  The invention described herein for enabling a smart card to become an Internet node is also applicable to future secure MMCs and is shown in FIG. 7 (e). In this embodiment, the peer I / O protocol (described in more detail below) is implemented at the peer I / O client 325 to carry Internet protocol data, eg, PPP frames, using the MMC bus protocol. Is done. In addition to the MMC bus, SPI is another communication interface to the MMC. Some MMC cards make it possible to select MMC mode or SPI mode. Therefore, the methods described above in the section describing the use of SPI in network smart cards also apply to secure MMC. The secure MMC can also communicate with the host or network using other multimedia transport protocols. FIG. 10 shows one exemplary configuration for creating a secure MMC as an Internet node. Other examples include replacing PPP and peer I / O with other link layer protocols and replacing TCP with other transport protocols such as UDP.

(NFC (Near Field Communication))
NFC (Near Field Communication) is a wireless interface and wireless protocol. NFC targets consumer electronic devices that are moving from isolated devices to networked devices. NFC devices communicate by approaching each other without requiring users to configure the network. The NFC interface operates in the unregulated RF band of 13.56 MHz. Communication is half duplex. The operating distance is approximately 0-20 cm (NFC is described in “Near Field Communication-white paper”, ECMA International, Ecma / TC32-TG19 / 2004/1).

  The NFC protocol distinguishes between an initiator and a target. The initiator device initiates and controls data exchange. The target device responds to the request from the initiator. The NFC protocol has two modes of operation: active mode and passive mode. In active mode, both devices generate their own RF electromagnetic fields that transmit data. In passive mode, only the initiator generates an RF electromagnetic field that is used by both the initiator device and the target device to transfer data. The NFC device sets the initial communication speed to 106, 212, or 424 kilobits per second. The active communication mode can reach much higher bit rates, 6 megabits per second ("Near Field Communication-Interface and Protocol (NFCIP-1)", Standard ECMA-340, December 2002).

  NFC is a very short-range wireless protocol. NFC is intuitively secured because two NFC devices must be very close to each other in order to communicate. The passive communication mode is an important function of NFC. A battery-powered mobile device, such as a mobile phone, or a mobile device that does not have a power source can communicate with other NFC devices without having to generate an RF electromagnetic field.

  NFC devices exchange data using NFC's DEP (Data Exchange Protocol). DEP is a request / response protocol. The initiator sends a request and the target transmits a response. An NFC device that does not generate RF electromagnetic waves always operates in a passive communication mode and is a target device. Such NFC devices are in a situation similar to standard ISO 7816 or ISO 14443 smart cards. Similar to the techniques previously described herein, peer I / O can be implemented using DEP. For example, an undefined bit setting in the DEP protocol header can be used to define a peer I / O command.

  If the network protocol is implemented in a passive NFC target device, peer I / O allows such a device to behave as a network peer, i.e. become an active device.

(Other applications)
The Dallas Semiconductor iButton® is a computer chip sealed in a 16 mm stainless steel can iButton® (http: //www.iButton®.com).

  iButton (R) can be attached to a key ring, ring, wristwatch, or other personal item. iButton® applications include access control to buildings and computers. iButton (R) communicates with the host computer via a read / write device. Communication uses a one-wire protocol where the data transfer is bit-ordered and half-duplex. iButton (registered trademark) is considered a slave, whereas a host having a reader / writer is a master. Peer I / O can be implemented using iButton ™ 1-wire protocol. The implementation allows iButton® to become an active peer and initiate communication.

  Many other devices, such as remote monitoring devices (eg, satellite modem monitoring, patient home monitoring), audio devices, and various control systems use half-duplex serial command / response (master / slave) communication protocols. . Peer I / O implementations can allow such devices to support networking protocols and become active peers in the network.

  From the foregoing, it is understood that the method and system of peer-to-peer communication provided by the present invention provides efficient and flexible peer-to-peer communication that allows resource-constrained devices to communicate as network peers. Let's do it. An electronic device that implements the method of the present invention or incorporates logic that operates in accordance with the method of the present invention is designed to communicate to a host device via a half-duplex serial command / response communication link, but is asynchronous Appears to be communicating at full duplex. The system and method for peer-to-peer communication according to the present invention minimizes the power consumption of host devices and resource-constrained devices, and is therefore preferably introduced in small portable devices with limited power supply capabilities. Is possible. Thus, the peer-to-peer communication system and method according to the present invention provides several advantages over existing communication systems.

  Although specific embodiments of the present invention have been described and illustrated, the present invention should not be limited to the specific forms or configurations of the parts so described and illustrated. The invention is limited only by the claims.

FIG. 2 is a schematic diagram illustrating an operating environment in which a networked electronic device according to the present invention can be installed. FIG. 2 is a schematic diagram illustrating an example architecture of the hardware of a networked electronic device 101 that can be used in connection with the present invention. FIG. 3 is a schematic diagram illustrating a software architecture implementation for a resource constrained device and a host computer. FIG. 3 is a schematic diagram illustrating a finite state machine that controls the behavior of a peer I / O server. FIG. 2 is a schematic diagram illustrating a finite state machine that controls the behavior of a peer I / O client. FIG. 3 shows a first alternative for connecting an infrastructureless network smart card according to the invention to a network. 1 is a high-level schematic diagram of a communication protocol stack, a host computer, and a network smart card that implement a peer I / O protocol in which APDUs carry PPP frames. FIG. FIG. 2 is a schematic diagram illustrating components for performing communication between a smart card and a network in which the smart card communicates with a host computer using a serial connection with half-duplex serial I / O. A smart card communicates to a hardware interface device via a half-duplex serial connection, and the interface communicates to a host computer using a full-duplex connection to implement communication between the smart card and the network. It is the schematic which shows a component. FIG. 2 is a schematic diagram illustrating an embodiment of components for introducing the present invention in connection with an MMC card.

Claims (5)

A method of communication between a resource-constrained device capable of independent half-duplex communication over a network and a host computer and a remote network node, wherein the host computer and the remote network node are not changed And a server to communicate with a resource-constrained device, the resource-constrained device having a central processing unit, random access memory, non-volatile memory, read-only memory, and input / output components A resource-constrained device is connected to the host computer via a physical communication link connection , the method comprising :
Establishing a physical link connection between the resource-constrained device and the host computer via the interface device ;
A communication implementing a networking protocol and one or more link layer communication protocols operable on a resource constrained device to communicate with an interface device and operable to communicate with a remote network node Running the module,
One or more secure networks running on the resource-constrained device that are driven by the input event and that invoke the communication module of the resource-constrained device to communicate with the host computer and the remote network node Operating resource-constrained devices according to the communication module driven by the application ;
Transfer device with a resource constraint, the interface device in one of the at least one condition that allows to transmit the start of the message according to a peer-to-peer communications protocol, messages between the devices and the networks of resource-constrained it possible to, and devices with a resource constraint, in response to not exhibit intended to transmit the start of the message at all, over a period of time, delaying the interaction with the device that is resource constrained, the Operating the interface device according to one finite state machine ;
Via the interface device, the resource-constrained device according to a second finite state machine that allows the resource-constrained device to forward messages to the host computer or remote network node according to the peer-to-peer communication protocol. To operate, and
Operating the resource-constrained device to thereby reduce power consumption to set a polling interval that indicates to the interface device the interval between polling message transmissions from the interface device to the resource-constrained device ; Method. The method of communication between a resource constrained device and a host computer and a remote network node according to claim 1, wherein the interface device is a hardware device connected between the host computer and the resource constrained device. The resource constrained device and host computer of claim 1, wherein the interface device is a software module that executes on a host computer between a physical link and a communication module that implements a higher level communication protocol. And a method of communication between remote network nodes . The resource constrained device of claim 1, further comprising: operating the interface device to perform a bridging function between a half-duplex serial connection and a full-duplex connection ; Way of communication between . The step of performing the bridging function is
Enabling resource-constrained devices operating in command / response mode to communicate with a network node as a peer;
Enabling resource-constrained devices operating in half-duplex serial communication mode to handle full-duplex communication traffic;
Encapsulating higher layer protocol frames;
To enable transport of higher layer protocol frames that exceed the frame size limit of lower link layer and to provide at least one function selected from supporting multiple logical connections of higher layer protocols The method of communication between a resource constrained device of claim 4 and a host computer and a mote network node .

Images