KR101172930B1 - System and method for data communications allowing slave devices to be network peers - Google Patents

Abstract

A system and method for peer-to-peer communication between a slave device and a network resource, wherein the application and the network node act as full-fledged network nodes in a manner that conserves power to be suitable for installation on small portable devices. While appearing, the slave device, for example a smart card, communicates using a protocol that allows the smart card to communicate over a half-duplex serial communication link.

Description

SYSTEM AND METHOD FOR DATA COMMUNICATIONS ALLOWING SLAVE DEVICES TO BE NETWORK PEERS}

The present invention discloses a U.S. application filed on February 11, 2005. Priority is claimed from 35 U.S.C. 119 of provisional patent application 60 / 652,291. Said provisional application is incorporated herein by reference.

Filed May 19, 2004, filed with U.S. In application 10 / 848,738, “Secure Networking Using a Resource-Constrained Device,” a resource-constrained device communicating using a half-duplex communication channel. Systems and methods for providing communication between remote nodes that are connected to a network are described. The present invention provides an improvement based on this.

Filed September 23, 2005, filed U.S. In patent application No. 11 / 234,577 “Communications of UICC in mobile devices using Internet Protocols”, a system for the UICC in a mobile device to function as a network peer and The method is described.

Co-filed November 30, 2000, U.S. Patent Application No. 09 / 727,174 “Smart Card Control of Terminal and Network Resources”, and Serial Application June 29, 1998, U.S. Pat. In patent application 09 / 107,033 (current US Pat. No. 6,157,966), a resource-constrained device still functions as a peer with the host device, while the resource-constrained device and the host device communicate on a semi-dual communication channel. Systems and methods for asynchronous communication are described.

The present invention relates to the operation of network-based electronic devices and, more particularly, to systems and methods that allow devices that are traditionally slaves to become network peers.

 In the new information age, the power of operations is growing. "Dumb" machines require some degree of "intelligence". As this trend continues, there is a higher level of expectations. For example, the previous generation of machines was not expected to have any computing power, and the next generation had only some computing power. An additional step in this evolution is to network the machines. However, because of physical size constraints, or because computational power and data storage are not the main functions of the machine, computational power and memory size may be very limited. These constraints have a great impact on the ability of resource-contrained devices to interact with other nodes on the network.

An example of such a resource-constrained device is a smart card. Smart cards are simply plastic cards that include integrated circuits with some memory and microprocessors. Typically this memory is limited to 6KByte RAM. In the next few years, it can be expected that smart card RAM can be increased to a few kilobytes. But memory size will continue to be an obstacle for smart card applications. Most smart cards have an 8-bit microprocessor.

The communication infrastructure provides another resource constraint for smart cards and similar devices. Smart cards do not have full-speed USB communication and lack a full-duplex serial interface. Smart cards now use an ISO-7816 interface that works half-duplex.

There is another device with similar resource constraints. For example, a USB dongle (such as an iKey device from SafeNet, Inc., Bellcamp, Maryland), or a secure integrated circuit chip attached directly to an SD card or PC motherboard.

Here, a device having a common resource limit, for example, RAM limited to less than 64K, is referred to as a "resource-constrained device." Resource-constrained devices include smart cards, USB dongles, SD cards, and secure integrated circuit chips attached directly to the PC motherboard. In addition, the term resource-constrained device may be any other device with similar resource constraints. For clarity, this application is primarily described in the context of smart cards. It is not intended to limit the spirit and scope of the present invention, but may equally apply to other resource-constrained devices.

Smart cards are used with a host, or a terminal, which may be a computer, or a cell phone, equipped with a smart card reader. When smart cards are connected to a computer, using standard mainstream network interfaces, host applications do not communicate with them. Certain hardware and software in the form of smart card reader devices and middle-ware applications need to access card services.

Patent application 10 / 848,738, filed together and assigned together, discloses a new protocol, so-called Peer I / O, for which smart cards and other half-duplex A resource-constrained device using a serial command / response communication protocol can handle full-duplex peer-to-peer communication. Therefore, a device using such Peer I / O can join the network as a network peer.

It is useful to have a system and method that is generally applied such that an apparatus communicating using a half-duplex serial command / response communication protocol can handle asynchronous full-duplex peer-to-peer communication.

In the current trend, electronic communication devices continue to be portable, compact and wireless. The challenge to be solved from this trend is that, by the advantage of wireless, the device must have its own power source, usually a battery. Since the battery is a limited resource until the device is connected back to the wired power source, the length of available power, i.e. simply battery life, is a major concern. The sales factor for portable devices depends on their size. Of course, the smaller the device, the smaller the battery, and consequently the shorter the battery life.

One of the most common resource-constrained devices is the SIM module for mobile phones. Over the years, many features and functions have been incorporated into mobile phones. Patent application 11 / 234,577, filed together and assigned together, "Communications of UICC in mobile devices using Internet Protocols" executes a web server on a SIM card, thereby providing a SIM card. Describes an application that can function as a network peer. Power consumption and its associated battery life are very important from the mobile phone's perspective. Thus, a system and method that enables an electronic device to communicate using a half-duplex serial command / response enables asynchronous full-duplex peer-to-peer communication while conserving power and thus extending the battery life of the mobile device. It may be desirable to have.

From the foregoing description, a full-duplex peer-while preserving power consumed by a resource-constrained device on a mobile device by a networked resource-constrained device communicating using a half-duplex serial command / response communication link. It will be apparent that there is still a need for improved systems and methods to enable two-peer communication.

The present invention provides, in a preferred embodiment, a system and method for peer-to-peer communication between a slave device and a network resource, wherein the slave device, e. Applications and network nodes are represented as full-fledged network nodes in such a way that they communicate using protocols designed to communicate over dual serial command / response communication links, while at the same time conserving power for being placed on small portable devices. Shown.

Other aspects and advantages of the present invention will become apparent from the following description.

1 is a conceptual diagram of an operating environment in which a networked electronic device according to the present invention is deployed.

2 is a conceptual diagram of an exemplary structure of hardware of a networked electronic device 101 that may be used in combination with the present invention.

3 is a conceptual diagram of a software architecture for a resource constrained device and a host computer.

4 is a conceptual diagram of a finite state machine that controls the operation of a Peer I / O server.

5 is a conceptual diagram of a finite state machine that controls the operation of a Peer I / O client.

6 is a diagram illustrating a first alternative to the connection of an infrastructure-free smart card to a network according to the present invention.

7 is a high-level conceptual diagram of a communication protocol stack and a host computer and a network smart card that implement the Peer I / O protocol in which the APDU carries PPP frames.

8 is a conceptual diagram of components for implementing communication between a smart card and a network in which a smart card communicates with a host computer using a serial connection with half-duplex serial I / O.

9 is a conceptual diagram of components for implementing a communication between a smart card and a network where a smart card communicates with a hardware interface device over a half-duplex serial connection and the interface communicates with a host computer using a half-duplex connection; .

10 is a conceptual diagram illustrating an embodiment of components for developing the present invention in combination with an MMC card.

In the following detailed description, reference is made to the drawings that show specific embodiments in which the invention may be implemented. These embodiments are made in sufficient detail to enable those skilled in the art to implement the present invention. The various embodiments of the invention are different but not mutually exclusive. For example, certain features, structures, or characteristics described herein in connection with one embodiment can be implemented within another embodiment within the spirit and scope of the invention. In addition, the position, or arrangement, of individual components within each described embodiment may be modified within the spirit and scope of the present invention. The following detailed description is not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims. In the drawings, like reference numerals refer to the same or similar functions.

As shown in the drawings for purposes of explanation, the present invention provides a network-enabled electronic device equipped with a peer-to-peer communication function for a network-enabled electronic device while minimizing power consumption; For example, it is implemented in network smart cards.

1 is a schematic illustration of an operating environment in which a network-connected electronic device according to the present invention may be deployed.

In one embodiment, the network-enabled electronic device 101 is a network smart card installed in the handset 103. The handset 103 may be a general accessory, such as a mobile phone having a keypad 105, a display 107, a microphone 109, and a speaker 111. In an alternate embodiment, the handset 103 may be a PDA or other mobile device using a SIM card. The handset 103 also includes an electronic circuit comprising a central processing unit and a memory. In addition, there are various smart mobile devices available, for example web-enabled phones, smart phones, PDAs, handheld PCs, tablet PCs. Many smartphones and PDAs combine cellular phones and PDA functions. Common operating systems for smart mobile devices include Symbian, Palm OS, and Microsoft Smartphone. If such a device has a SIM device, i. E. Network smart card 101, the invention can be applied to such a device.

Electronic circuitry provides a communication function with wireless network 117 to wireless telephone antenna 119 via a wireless link for handset 103. The microprocessor provides some of the control functions of the handset 103, such as managing the operation of the handset 103, and managing the communication protocols used to communicate with the wireless network 117. The network smart card 101 is connected by electronic circuitry to enable communication between the network smart card 101 and the handset 103.

The wireless network 117 consists of a complex communication intrastructure for providing connectivity with other stations, such as other mobile stations, or land-based telephone systems. This station may be an Internet gateway 121 that provides wireless network 117 access to the Internet 12. As is generally known, many computers are connected via the Internet. In the scenarios provided herein, a user of a handset, such as a mobile phone or PDA, can use a network smart card through the handset 103, or other computer connected to the Internet 125, using the infrastructure shown in FIG. Communicate with 101. In some aspects of this communication, 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. This is used.

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

The network smart card 101, or 101 ′, is a smart card that can function as an autonomous Internet node. Network smart cards are described in patent application No. 10 / 848,738, "SECURE NETWORKING USING A RESOURCE-CONSTRAINED DEVICE," filed May 19, 2004, filed with the same application. Cited by reference. The network smart card 101 can implement the Internet protocol (TCP / IP) and security protocol (SSL / TLS) embedded in the card, and implement other communication protocols to be described below. The network smart card 101 may establish and maintain a secure Internet connection with other Internet nodes. In order to enable internet communication, the network smart card 101 does not depend on the proxy on the host. In addition, the network smart card 101 does not require a local Internet client / server, or a remote Internet client / server to be modified to communicate with the smart card.

The present invention is also suitable for use in other devices, such as other network-capable resource-constrained devices, but is not limited to resource constrained devices. For example, a network-enabled electronic-device according to the present invention may be a computer 101 ". As used herein, the term network-enabled electronic-device refers to other electronics-. Refers to any electronic device that is connected through a network to a device and is capable of electrically communicating with another device Similarly, reference numeral 101 is used to refer to any such device, and specifically refers to one device. It is not.

The network-connected electronic device may be a network smart card, such as smart card 101 ′. Patent Application No. 10 / 848,738, filed on May 19, 2004, entitled “SECURE NETWORKING USING A RESOURSE-CONSTRAINED DEVICE,” which is hereby incorporated by reference. An existing network smart card combines the functionality of a conventional smart card to act as an autonomous network node by implementing a communication protocol stack used for network communication. When the network-connected electronic device 101 is connected to the network through the host computer 103 ', the host computer 103' may be an attacking computer, for example, a reflector. Or by having some malware installed on them.

2 shows an exemplary structure of hardware of a network-connected electronic device 101 that can be used in combination with the present invention. The network-connected electronic device 101 according to the example of FIG. 2 includes a central processing unit 203, read only memory (ROM, 205), random access memory (RAM, 207), and non-volatile memory (NVM, 209 and a communication interface 211 for receiving input and delivering output to a computer network, such as the Internet, wherein the network is directly connected to the communication interface 211 via a relay device such as a host computer 103 '. The connected electronic device 101 is connected. These various components are connected to each other by, for example, a bus 213. In one embodiment of the present invention, the communication module 321, as well as other software modules described herein below, are stored on the resource-constrained device 101 of the ROM 205. In alternative embodiments, software modules stored in ROM 205 are stored in flash memory, or some other type of non-volatile memory. For purposes of explanation, the invention is described by way of example of a ROM. However, it is not intended to limit the scope of the present invention, and wherever a ROM is used, flash memory and other types of non-volatile memory may alternatively be configured.

The ROM 205 also incorporates some type of operating system, such as a Java Virtual Machine. Alternatively, communication module 321 is part of the operating system. During operation, the CPU 203 operates in accordance with the instructions of various software modules stored in the ROM 205 or the NVM 209.

Accordingly, according to the present invention, the CPU 203 may operate in accordance with instructions in the communication module 321 to perform various operations of the communication module 321 described below.

3 conceptually illustrates a software architecture for the resource constrained device 301 and the host computer 303. In the context of FIGS. 1 and 2, the resource constrained device 301 may be a SIM card 101, or a network smart card 101 ′, and the handset 303 is a handset 103, or a host computer. (103 ').

The host computer 303 has network applications 305a, 305b, and 305c loaded therein (note that for the handset 103, the physical structure of the handset is very similar to the physical structure of the computer). The handset 103 thus has a memory and a processor, the memory comprising RAM, ROM, EEPROM, etc. The memory contains a software module that controls the operation of the processor. The various software modules shown as being part of 303 are generally stored in the non-volatile memory of the mobile device and loaded into RAM during execution, from which such software module instructions control the operation of the processor and allow the mobile device to be specific. Operation, such as establishing a network connection). Examples of such applications are web browsers and network contacts list applications. In the case of a web browser, the application 305a is configured to access the resource-constrained device 301, or more precisely, to communicate with a web server running on the resource-constrained device 301, such as the SIM card network application 307a. Can be used.

The host computer 303 and the resource constrained device 301 communicate over several layers of communication protocols. In one embodiment, this layer may appear as several communication software modules, for example TCP / IP module 317, which handles communication at the TCP / IP level on host computer 303, and resource-constrained. There is a corresponding TCP / IP module 327 on the device 301 and a host computer 303 for communicating according to the Peer I / O protocol with the PPP modules 318 and 329 for handling communication at the PPP level. There is a Peer I / O server module 315 on s) and a corresponding Peer client module 325 on a resource-constrained device 301. The operations of the Peer I / O client module 325 and Peer I / O server module 315 are described in detail below.

The resource-constrained device 301 and the host computer 303 are connected as a hardware layer, for example via a USB or wireless connection, and thus have hardware communication modules 318 and 319 for maintaining hardware level communication.

The host computer 303 may establish a connection with an external data network and support several applications 305a-c. An application program on the host computer may use the communication module 311 to establish a connection to the external 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 described in the previously filed Patent Application No. 10 / 848,738, filed May 19, 2004, entitled “SECURE NETWORKING. USING A RESOURCE-CONSTRAINED DEVICE), which is hereby incorporated by reference. Virtual serial port 313 implements the serial port interface defined by the operating system of handset 303. Communication between network SIM cards (also known as network UICC card locks) is described in the patent application filed September 23, 2005, "Communications of UICC IN MOBILE DEVICE USING INTERNET PROTOCOLS." It is described in more detail, the application of which is incorporated herein by reference.

The Peer I / O implementation is located on the host 303 and the device 301. At the host side, the Peer I / O provides a service for sending messages between the device 301 and the network 117. At this time, such a service module is referred to as a Peer I / O server 315. The device 301 is located above a low-level half-duplex serial communication protocol 318 operating at a command / response, and is located under a full-duplex protocol such as Peer I / P 329. Contains the client 325. This full-duplex communication is asynchronous. This is because the end of the communication channel can be synchronized with the rest of the end or transmitted at any time without timing. The Peer I / O protocol is independent of the higher level protocol performed. In terms of higher layer protocols, Peer I / O can carry messages in both directions. For example, Peer I / O can be used to carry PPP frames, or Ethernet frames, or IP datagrams. In other words, the fact that data communication between the resource-constrained device 301 and the host 303 is performed through a half-duplex serial command / response link, means that the resource-constrained device 301 and the host 303 are connected with each other. It is transparent to higher level applications and communication protocols on other network nodes capable of communicating with the resource-constrained device 301.

When a computer (or simply a network) on a network sends a message to a device, the Peer I / O server 315 sends the message by sending one or more commands of the command / response communication protocol containing the message to the device 301. do. The Peer I / O server 315 periodically polls the device 301 for the device 301 to send a message to the network 117 whenever it needs to send. When the device has a message, the Peer I / O server 315 issues one or more commands to obtain the device message and send it to the network. The operation of these devices 301, 303 to effect communication over a half-duplex serial command / response link connecting the devices 301, 303 is performed by the Peer I / O server 315 and Peer I / O client ( 325. In one embodiment of the present invention, this operation is performed in accordance with a finite state machine on the resource-constrained device 301 and the host device 303. By means of the Peer I / O finite state machine, communication can be performed using high-level messages of any length, without using explicit fragmentation and assembly mechanisms.

Peer  I / O protocol format ( Peer  I / O Protocol Format )

The Peer I / O protocol defines three commands: Put Packet, Get Packet, and Poll. The Put Packet command sends data from the host to the device. The Get Packet command gets data from the device to the host. The Poll command is used by a host to check a device to see if the device has data to be sent. Execution of these commands is protocol dependent. When feasible, the Poll command can be executed as a Put Packet command without data. In this case, the Peer I / O protocol requires only two commands, namely Put Packet and Get Packet.

The Peer I / O command type may be represented by one byte, two bits, or even one bit, depending on the underlying protocol. The Put Packet command generally has the following format.

Put Packet Length Data

In this case, Length is the length of data transmitted from the host to the device. After receiving a Put Packet command from the host, the device obtains data and returns a status.

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

Get packet Length

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

The Poll command usually requires no parameters. After receiving the Poll command from the host, the device sends status.

The status returned from the device to the host may indicate several things, including the following.

• There is data of length n to be transmitted.

• There is no data to be transmitted.

No data to be transferred; Set the polling interval. The polling interval may be infinite, meaning "don't poll, waiting for data."

Lower protocols typically limit the length of data in a packet. For example, the binary protocol limits data to 256 bytes. The Peer I / O protocol is related to the limitations of the lower protocol. This makes it possible to send and receive larger packets by issuing multiple put or get commands as needed. The Peer I / O protocol assumes that the upper layer protocol knows the boundary of its packet.

Peer  I / O protocol behavior ( Operations of the Peer  I / O Protocol )

This section describes the typical operation 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.

Put Packet Length Data

When the device wants to send data to the network, it needs to wait for the opportunity. The Peer I / O server 315 polls periodically to give the device an opportunity to transmit. The server issues a POLL command.

POLL

After receiving the command from the Peer I / O server 315, if the device has no data to send, it sends a status indicating yes. If the device has data to transmit, it sends a "has data" status and transmits the length of the data the device is about to transmit.

When the Peer I / O server 315 receives a status indicating that the device has data to send, it issues a Get Packet command.

GET_PACKET Length

The device responds with a response containing data.

Data Status

If the status indicates additional data to send, the Peer I / O server 315 may issue another Get Packet command.

Controlled polling ( Controlled Polling )

The host's Peer I / O server 315 polls the device periodically to see if the device has data to send. This polling is controlled by a polling interval, which is infinite. This controlled polling reduces the power consumption that occurs when device 301 is polled continuously by host 303.

Peer I / O forms a new return state that can specify the polling interval. The default polling interval is "as often as possible". The interval may be specified in seconds, minutes, or hours. The Peer I / O server 315 will poll as close as possible to the polling interval. The polling interval may also be infinite. When the device waits to receive data, it may specify an infinite polling interval. In this case, the Peer I / O server 315 will not poll the device and only contact the device when there is data available to the device. For example, when the device is a web server and is waiting for a client connection, the device can set the polling interval to infinity. For example, when the host is a small mobile device powered by a battery and the device consumes the power supplied by the host, this new addition to Peer I / O is very important for mobile applications.

For example, the return state can be represented by two octets. The 4 most significant bits represent "having data" or "no data". In the case of "having data", the remaining bits may indicate the length of the data. In the case of "no data", the remaining bits are all zeros, which means "use current polling interval", which may be the default polling. If all other bits are 1, it means "do not poll". Otherwise, the next two bits represent the unit of the polling interval, such as seconds, or minutes, or time. The remaining 10 bits represent the polling interval.

For example, the following figure shows the return status for the case of 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.

9 is a conceptual illustration of a finite state machine 901 that controls the operation of a Peer I / O server 315.

The finite state machine (FSM) 901 has five states.

Initial State (902)

Polling (903)

ㆍ Getting from the Client (905)

ㆍ Pushing Data to Client (909)

Checking the Network for Data (907)

There are four events.

4 types of return status from client

   ° client has data (cd)

  The client has no data and does not change the polling interval (cnd)

  The client has no data and changes the polling interval (cnd + p)

  The client has no data and does not poll (cnd + np)

Two results from network checking

  ° Network has no data (nnd)

  ° network has data (nd)

• There are four actions.

  Get a packet from the client

  Put the packet to the client

  Get packets from the network

  ° Packing packets into the network

Peer I / O server 315 is initiated by Peer I / O client 325. In response, to wait before sending back to the Peer I / O client 325, the client 325 may indicate whether it has a data transmission and a polling interval for the Peer I / O server 315. .

Whenever the Peer I / O client 325 returns a status cd, the transition 401 indicates that the client 325 has data to send. In response, Peer I / O server 315 obtains data from client 325 and sends the data to network 117. By issuing a Get_Packet action, state 905, server 325 continues to obtain data from client 315, and so long as client 315 returns a state cd (transition 403). Send to the network.

By returning the value cnd, the Peer I / O server 315 checks the network when the client returns a status that it has no data to send, or is ready to receive (state 907). Transition to furnace (407). If the network has data, the Peer I / O server 315 obtains the data from the network and sends the data to the client 325 (transition 409 to state 909). If the network has no 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 last transmission to the client 325 reaches the polling interval (timeout), the Peer I / O server 315 polls the client 325 (status 903). Transition 411), otherwise, if the polling interval has not been reached (! Timeout), server 315 remains "network checking" (state 907, transition 413).

5 is a conceptual illustration of a finite state machine 501 that controls the operation of a Peer I / O client 325.

The Peer I / O client state machine has four states.

ㆍ Initial State, State (503)

Wait for a higher layer instruction (read or write), state 505

ㆍ Ready to write, waiting for peer I / O server, status (507)

ㆍ Read Ready, Peer I / O Server Wait, State (509)

There are five events.

• Reading instructions from the upper layer

• Write instructions from the 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

There are four actions.

To send the status "Client has data" (cd) to Peer I / O server 315

Sending status "client has no data" (cnd) to Peer I / O server 315

  ° Client does not have data and does not change polling interval (cnd)

  ° Client has no data and changes polling interval (cnd + p)

  ° Client does not have data and does not poll (cnd + np)

ㆍ Get data from Peer I / O server 315

ㆍ Send data to Peer I / O server 315

The device 301 operates the Peer I / O client 325 starting in the initial state 503. Applications 307a-c that communicate through a higher layer, such as TCP / IP module 327, may request write or read. For example, when device 301 wants to initiate a connection, application 307 on device 301 may initiate a connection by sending a first message (Peer I / O protocol initiates the connection. Regardless of whether it is a device or host to initiate). When the upper layer issues a write instruction, the Peer I / O client 325 leaves its "initial" state 503 and moves to the "ready write" state 507. (Transition 511). When the server 315 issues a Get Packet command, the client 325 transfers data and moves to a "wait upper" state 505 (waiting for a higher layer instruction) (transition 514). )).

When the client 325 is in the "wait upper" state 505, when the upper layer issues a "write", the client 9325 may send a state cd to the Peer I / O server 315. Is sent to " ready write " state 507 (transition 516). On the other hand, when the upper layer issues a "read", the client 325 sends a state cnd to the Peer I / O server 315 and enters the "ready read" state 509. Move (transition 517). The client 325 reads "ready" from the "initial" state 503 when it receives a "read" instruction from a higher layer while the client 325 is in the "initial" state 503. read "state 509 (transition 521). When in the " ready read " state 509, the client 325 sends another cnd and remains in the " ready read " state 509 (transition 519). . If server 315 issues a Put Packet command, client 325 obtains the data and moves to " wait upper " state 505 (transition 515).

Application example ( application )

The Peer I / O protocol has many applications. The first example is to connect the network smart card to the internet via a host computer.

Smart cards are small cards that contain a microprocessor chip. The ISO defines two form factors for a smart card, namely a credit card type card and a Subscriver Indentification Module (SIM) card. Smart cards are secure, portable and tamper resistant. They serve the purpose of security for a wide range of applications, for example in mobile communication (SIM card embedded in cell phones), banking, physical access control, network access control, transport, digital identity and the like. Unfortunately, smart card communication standards do not conform to the standards of mainstream computing, which limits the success of smart cards.

The current smart card standard ISO 7816 (ISO 1443 for non-contact smart cards) specifies a half-duplex serial command / response communication protocol, while standard Internet protocols such as PPP, IP and TCP are full-duplex and peer. Operate in two-to-peer mode. By applying Peer I / O, the current smart card compatible with the ISO 7816 (or ISO 14443) standard can be an Internet node. This section describes the implementation of Peer I / O using ISO 7816 commands.

6 shows a first alternative for connecting an infrastructure-free network smart card 301 to the network 117 according to the present invention. The infrastructureless network smart card 301 is connected to a reader 302, which is connected to a host computer 303. The computer 303 is connected to a network 117. The computer 303 functions as a router for routing Internet communications to the card 301 or for routing Internet communications from the card. The computer 303 has a first IP address for connecting to the network 117 and a second IP address for connecting to the infrastructure-free network smart card 301. There is a third IP address associated with the infrastructure-free network smart card 301. The third IP address may be assigned to the card 301 or dynamically assigned.

The computer 303 has a Remote Access Server (RAS) that provides Internet services to other computers connected to it. If the smart card 301 has full-duplex serial I / O, like other full-duplex serial devices, the smart card with TCP / IP / PPP does not load any additional software on the computer 303 without the RAS. Internet connection can be established through. In practice, smart card standards specify half-duplex serial I / O. In addition to the full dual vs half-duplex problem, the Internet protocol is peer-to-peer, which allows nodes to talk as they wish, whereas the ISO 7816 and ISO 14443 protocols are smartcards. Specifies a command / response operation that only responds to commands issued by the terminal. The Peer I / O protocol implemented in accordance with the present invention solves all of these protocol non-compliance issues.

Peer I / O implementations in accordance with the present invention exist as communication modules operating together on the smart card 301 and on the host computer 303 (or reader 302). The host computer (or reader) contains a Peer I / O server 315 that provides a service for sending messages between the card and the RAS on the host. The card contains a Peer I / O client that exists in the ISO 7816 dominance and is located below other protocols such as PPP.

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

7 is a high-level conceptual diagram of a communication protocol stack for a host computer 303 and a network smart card 301 implementing the Peer I / O protocol.

In an embodiment of the present invention comprising a link-layer protocol, herein Peer I / O, the Peer I / O module is present in both the host computer 303 (or reader) and the card 301. do. In the protocol stack of the host PC side 303, the Peer I / O server module 315 implements the Peer I / O protocol layer, and the card 301 and the Remote Access Server (RAS) on the host computer 303, 701 provides a service for sending a message between. On the smart card 301 side, the protocol stack contains a Peer I / O protocol layer 325 that sits on top of the APDU 807 and sits under another protocol, such as the PPP 329. The APDU provides communication between the host 303 and the card 301. The Peer I / O protocol is independent of the internet protocol being executed. In terms of protocols from higher layers, Peer I / O can carry messages in both directions. For example, Peer I / O can be used to carry PPP frames, or Ethernet frames, or IP datagrams. Peer I / O uses APDUs to carry messages such as PPP frames, Ethernet frames, or IP datagrams. In the following description of Peer I / O, PAS and PPP are used as examples. In this case, Peer I / O uses the APDU to carry the PPP frame.

When the RAS sends a message to the card 301, the Peer I / O server 315 sends the message by sending one or more APDU commands containing the message to the card 301. In order for the card 301 to send a message to the RAS, the Peer I / O server 315 periodically polls the card 301. The finite state machines of the Peer I / O server 315 and Peer I / O client 325 form a mechanism for sending messages of any length without using explicit fragmentation and assembly mechanisms. .

Peer  I / O protocol format ( Peer  I / O protocol Format )

The following is 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 reserved 0x10-0x7F CLA numbers for future use, ISimplify uses 0x10 ). Three instructions are defined for this Peer I / O class: POLL, GET_PACKET and PUT_PACKET. The Peer I / O server 315 can poll the card to see if the card wants to send anything using POLL, and get data from the card using GET_PACKET. And data can be sent to the card using PUT_PACKET. The Peer I / O protocol does not have its own protocol data unit. Use APDU directly.

Peer I / O command APDU has the following format.

0x12 INS Null Null Length (Data)

 The instruction INS may be one of the following.

POLL (0xE8): Length = 1; The data is any one byte

PUT_PACKTET (0xEA): Length is the number of bytes of Data to be sent to the card.

GET_PACKET (0xEC): Length is the number of bytes of Data (data) received from the card.

Length is 1 byte, so the maximum data length is 256 bytes. Note that the POLL command sends an arbitrary byte. This is to avoid ISO 7816 Case 1 commands that have no ACK to be sent by the card and some readers do not work well.

The response APDU has the following format.

ACK (Data) SW1 SW2

The ACK indicates an acknowledgment from the card for receiving a command from the Peer I / O server 315. The ACK is the INC code of the received command. The status of the process on the card side is indicated by SW1 and SW2 in the response APDU. For all three Peer I / O instructions, the response status is as follows.

READY-WRITExx (eg 6Cxx): xx represents the number of bytes the card is preparing to transmit

NO-DATA (eg 9000): The card is ready to receive.

9xxx: Card sets polling interval

The reason for using 6Cxx for normal condition is as follows. The IOP API on the host side does not export the status of APDU commands. Thus 6Cxx is used so that Peer I / O server 315 can catch it as an exception.

Peer  I / O behavior ( 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. The APDU contains data.

0x12 PUT_PACKET Null Null Length Data

 When the card wants to send data to RAS, it needs to wait for the opportunity. The baby Peer I / O server 315 may poll periodically to give the card an opportunity to send. The server issues a POLL command.

0x12 POLL Null Null One One

After receiving the command APDU from the Peer I / O server 315, the card first responds with an ACK. If the card does not have data to transfer, set SW1 SW2 to NO-DATA (eg 90 00).

ACK 90 00

If the card has data to transmit, SW1 SW2 is set to 6Cxx, where xx is the length of data that the card wants to transmit.

ACK 6C xx

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

0x12 GET_PACKET Null Null xx

The card responds with a response APDU containing the data.

ACK Data SW1 SW2

When SW1 SW2 = 6Cxx, the Peer I / O server 315 may issue another GET-PACKET command.

smart On the card  avatar( Implementation on  a Smart Card )

8 and 9 illustrate two alternative implementations of a peer-to-peer communication system in accordance with the present invention in a smart card system.

8 is a conceptual illustration of a voice for implementing communication between a smart card and a network, where a smart card communicates to a host computer using a serial connection with half-duplex serial I / O. The smart card 301 is connected to a reader 302 to a host computer 303. The driver of the reader implements a Peer I / O server 315. Together with the serial port driver 803, the composite driver acts as a (virtual) serial port at the point of view of the host computer 303. The standard RAS connection to the virtual serial port enables network connection to the smart card 301.

Peer I / O server 315 may be implemented in hardware of a smart card reader. 9 is a conceptual illustration of components for implementing communication between a smart card and a network, where the smart card communicates with a hardware interface device over a half-duplex serial connection, the interface using a full-duplex connection to a host computer; Communicate with The reader 302 is connected to the host computer 303 via a serial connection or a USB connection (when using a USB connection, USB / serial conversion is required at the reader and the host computer). Again, the standard RAS connection to the serial port allows for network connection to the smart card 301.

Multimedia card ( MMC )

In another embodiment, the present invention is used to connect a MultiMedia Card (MMC) to a network. In this embodiment, the MMC card plays almost the same role as the network smart card 201 described herein.

Multimedia cards (MMC) are small (24mm x 32mm, or 18mm x 1.4mm), removable, solid memory cards for mobile applications, such as cell phones, digital cameras, MP-3 music players, PDAs. MMC's storage capacity reaches 1Gbyte of data. High speed MMCs can transfer data at speeds up to 52 Mbits / second. MMC uses flash technology to read / write an application, or ROM to read only the application, or flash technology.

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

Security MMC adds smart card security features to MMC for content protection and electronic transactions. A tamper resistant module is included for secure storage in the card and can be encrypted and authenticated. For example, the Infineon technique uses its smart card hardware technique in its secure MMC. The secure MMC is fully compatible with the standard MMC.

Recently, the Multimedia Card Alliance (www.mmca.org) has formed a working group to standardize the next generation of secure multimedia cards (Security MMC) (www.mmca.org/press/SecurityFinal.pdf). This new specification, V.2.0, defines an extension of the MMC standard protocol to create a communication interface for applying smart card techniques. Accordingly, the MMC can provide smart card security features such as encryption and authentication. The extended MMC command set allows the MMC interface to carry a standard smart card ISO 7816 APDU.

The present invention, which allows a smart card to be an Internet node, is applied to characterize a secure MMC, which is shown in Figure 7 (e). In this embodiment, the Peer I / O protocol (described in more detail later) may be implemented in the Peer I / O client 325 using the MMC bus protocol to carry Internet protocol data, such as PPP frames. SPI is another communication interface to the MMC, in addition to the MMC bus. Some MMC cards can choose MMC or SPI mode. Thus, the previously provided method of describing the use of SPI in network smart cards also applies to secure MMC. In order to communicate with a host or network, the secure MMC may use other multimedia transport protocols. 10 shows one example configuration for making 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.

Near field communication ( NFC : Near Field Communication )

The near field communication (NFC) is an air interface and protocol. This targets consumer electronics moving from an isolated device to a network device. The NFC devices communicate by getting closer to each other without the user having to configure the network. The NFC interface operates in an unregulated RF band of 13.56 MHz. The communication is half-duplex. The operating distance is about 0 to 20 cm (NFC is described in "Near Field Communication", ECMA International, Ecma / TC32-TG19 / 2004/1).

The NFC protocol distinguishes an initiator from a target. The initiator device initiates and controls data exchange. The target device responds to a request from the initiator. The NFC protocol has two modes of operation, active mode and passive mode. In the active mode, both devices generate their own RF field for carrying data. In passive mode, only the initiator generates an RF field, which both the initiator device and the target device use to transmit data. The NFC device sets an initial communication rate at 106,212, or 424 kbit / s. The active communication mode may reach a higher bit rate of 6 Mbit / s (“Near Field Communication Interface and Protocol (NFCIP-I)”, standard ECMA-340, November 2002).

NFC is a very short range wireless protocol. Intuitively, this is safe because the two NFC devices must be located very close to each other in order to communicate. Passive mode of communication is an important feature of NFC. A battery powered mobile device, such as a mobile phone or a mobile device without a power source, can communicate with other NFC devices without having to generate an RF field.

The NFC device exchanges data using a data exchange protocol (DEP) of NFC. The DEP is a request / response protocol. Initiator sends urine layer and target sends response. NFC devices that do not generate an RF field always operate in the passive mode of communication and become target devices. This is similar to the standard ISO 7816, or ISO 14443 smart card. Similar to the techniques mentioned above, we can implement Peer I / O using DEP. For example, to define a Peer I / O command, you can use an undefined bit setting in the DEP protocol header.

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

Etc Application example

Dallas Semiconductor's iButton is a computer chip embedded in 16mm stainless steel (http://www.ibutton.com).

The iButton may be attached to an electronic key fob, ring, watch, or other personal item. Applications of the iButton include access control to buildings and computers. The iButton communicates with a host computer via a reader / writer device. This communication uses a one-wire protocol in which the data transmission is bit sequenced and semi-duplex. While the host containing the reader / writer is a master, the iButton is considered to be a slave. Peer I / O can be implemented using this iButton single-wire protocol. By such an implementation, the iButton may become an active peer and initiate communication.

Many other devices use half-duplex serial command / response (master / slave) communication protocols, for example remote monitoring devices (eg satellite modem monitoring, patient home monitoring), audio devices and various control systems. . By Peer I / O implementation, these devices will support networking protocols and become active peers in the network.

From the foregoing description, it will be apparent that the peer-to-peer communication method and system provided by the present invention provide effective and flexible peer-to-peer communication while allowing resource-constrained devices to communicate as network peers. will be. Although an electronic device comprising logic implemented or operating in accordance with the method of the present invention is designed to communicate with a host device via a half-duplex serial command / response communication link, Self-explanatory Systems and methods for peer-to-peer communication in accordance with the present invention add minimal power consumption to host and resource-constrained devices, and thus may be advantageously deployed in small portable devices with limited power supply capacity. Thus, the systems and methods of peer-to-peer communication in accordance with the present invention provide several advantages over existing communication systems.

Claims (12)

In a method of communicating via a network between a resource-constrained device capable of only half-duplex communication and a host computer and a remote network node, the host computer and the remote network node are networked. Communicate with the resource-constrained device using a client and server, the resource-constrained device having a central processing unit, random access memory (RAM), non-volatile memory, read-only memory (ROM), And a resource-constrained device, the resource-constrained device being connected to the host computer via a physical communication link connection. Establishing a physical link connection between the resource-constrained device and the host computer via an interface device; Executing a communication module on the resource-constrained device, the communication module implementing one or more link layer communication protocols and a networking protocol operative to communicate with the interface device and to communicate with the remote network node, Operating the resource-constrained device in accordance with a communication module, wherein the communication module is operated by an input event and by one or more secure network applications running on the resource-constrained device. , The network application requesting a communication module of the resource-constrained device to communicate with a host computer and a remote network node, Operating the interface device according to a first finite state machine which causes the interface device to send a message between the resource-constrained device and the network, wherein the interface device is A period of time, indicating that the resource-constrained device initiates and transmits a message according to a peer-to-peer communication protocol and indicates that the resource-constrained device does not initiate and intend to transmit a message During a state in one of one or more states which is a state which delays interaction with the resource-constrained device, Operate the resource-constrained device according to a second finite state machine that causes the resource-constrained device to send a message to a host computer or to a remote network node via an interface device according to a peer-to-peer communication protocol. Making the step, and Operating the resource-constrained device to set a polling-interval that indicates to the interface device an interval between polling message transmissions from the interface device to the resource-constrained device. Communication method comprising a. 2. The method of claim 1 wherein the interface device is a hardware device coupled between a host computer and a resource-constrained device. The method of claim 1, wherein the interface device operates using a software module running on a host computer between the physical link and the communication module implementing the high level communication protocol. The method of claim 1, Operating the interface device to perform a bridging function between a half-duplex serial connection and a full-duplex connection Communication method characterized in that it further comprises. The method of claim 4, wherein performing the bridging function The ability to communicate with a network node as a peer to a resource-constrained device operating in command / response mode, Resource-constrained device operating in half-duplex serial communication mode to handle full-duplex communication traffic; The ability to encapsulate upper layer protocol frames, The ability to enable transmission of higher layer protocol frames that exceed the frame size limit of the lower link layer, and Ability to support multiple logical connections of higher layer protocols And providing one or more of the following functions. delete delete delete delete delete delete delete

Images