Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
  • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
  • H04W80/02—Data link layer protocols
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
  • G06K17/00—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/12—Arrangements for remote connection or disconnection of substations or of equipment thereof
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

• the present invention relates to the operation of network-based electronic devices, and more particularly, to systems and methods for allowing devices that are traditionally slaves to be network peers.
• a smart card is simply a plastic card containing an integrated circuit with some memory and a microprocessor. Typically the memory is restricted to 6K bytes of RAM. It is anticipated that smart card RAM may increase by a few kilobytes over the next few 25
• USB dongles such as the iKey device sold by SafeNet, Inc., Belcamp, Maryland
• SD Cards Secure Digital Cards
• resource-constrained devices include smart cards, USB dongles, SD cards and secure integrated circuit chips attached directly to PC motherboards.
• resource-constrained device shall include any other devices that have similar resource constraints to these enumerated devices.
• the invention is described herein primarily in the context of smart cards. This must not be construed to limit the scope or applicability of the invention as it is equally applicable to other resource-constrained devices.
• Smart cards have been used with a terminal or a host, which may be a computer having a smart card reader, or a cell phone, or other devices.
• a terminal or a host which may be a computer having a smart card reader, or a cell phone, or other devices.
• host applications cannot communicate with them using standard mainstream network interfaces.
• Specific hardware and software in the form of smart card reader device drivers and middle-ware applications are needed to access the card services.
• Peer I/O Secure Networking Using a Resource Constraint Device
• Peer I/O a new protocol called Peer I/O, which enables smart cards and other resource-constrained devices using half-duplex serial command/response communication protocol to handle full- duplex peer-to-peer communications (hereinafter, the '"738" application).
• Peer I/O may join a network as a network peer.
• SIM module for mobile telephones.
• mobile telephones have been provided with many new features and functionality.
• the invention provides 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 command/response 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.
• the slave device for example, a smart card
• Figure 1 is a schematic illustration of the operating environment in which a network-connected electronic device according to the invention may be deployed.
• Figure 2 is a schematic illustration of an exemplary architecture of the hardware of a network-connected electronic device 101 that may be used in conjunction with the invention.
• Figure 3 is a schematic illustration of the software architecture implementation for a resource constrained device and a host computer.
• Figure 4 is a schematic illustration of the finite state machine that controls the behavior of the Peer I/O server.
• Figure 5 is a schematic illustration of the finite state machine that controls the behavior of the Peer I/O client.
• Figure 6 is an illustration of a first alternative for connecting an infrastructureless network smart card according to the invention to a network.
• Figure 7 is a high-level schematic diagram of the communications protocol stack, a host computer and a network smart card implementing the Peer I/O protocol in which APDU carries PPP frames.
• FIG. 8 is a schematic illustration of the components for implementing communication between a smart card and a network wherein the smart card communicates to a host computer using a serial connection having half-duplex serial I/O.
• FIG. 9 is a schematic illustration of the components for implementing communication between a smart card and a network wherein the smart card communicates to a hardware interface device over a half-duplex serial connection and the interface communicates to the host computer using a full-duplex connection.
• Figure 10 is a schematic illustration illustrating an embodiment of the components for deploying the invention in conjunction with MMC cards.
• the invention is embodied in a network enabled electronic device, e.g., a network smart card, equipped with the capability of providing peer-to-peer communication for a network enabled electronic device while minimizing power consumption.
• a network enabled electronic device e.g., a network smart card
• Figure 1 is a schematic illustration of the operating environment in which a network-connected electronic device according to the invention may be deployed.
• a network-enabled electronic device 101 is a network smart card installed into a handset 103.
• the handset 103 may be a mobile telephone having the usual accoutrements of a mobile telephone such as a keypad 105, a display 107, a microphone 109 and a speaker 111.
• the handset 103 may be a personal digital assistant or any other mobile device using a SIM card.
• the handset 103 also contains an electronic circuitry (not shown) including a central processing unit and memory.
• smart mobile devices available, such as web-enabled phones, smart phones, PDAs, handheld PCs and tablet PCs. Many of the smart phones and PDAs combine the cell phone and PDA functionalities.
• Popular operating systems for smart mobile devices include Symbian, Palm OS, and Microsoft Smartphone. The invention described herein is applicable to such devices if they have SIM device that is a network smart card 101.
• the electronic circuitry provides communications functionality for the handset 103 with a wireless network 117 via a wireless link to a wireless telephony antenna 119.
• the microprocessor provides some of the control functionality of the handset 103, such as managing operations of the handset 103 and managing communications protocols used to communicate with the wireless network 117.
• the network smart card 101 is connected to the electronic circuitry so as to allow communication between the network smart card 101 and the handset 103.
• the wireless network 117 is composed of a complex communications infrastructure for providing connections to other stations, for example, other mobile stations or land-based telephone systems.
• One such station may be an Internet gateway 121, which gives the wireless network 117 access to the Internet 125.
• Internet gateway 121 which gives the wireless network 117 access to the Internet 125.
• very many computers are connected via the Internet.
• a user of a handset e.g., a mobile telephone or a PDA, uses the infrastructure illustrated in Figure 1 to communicate with the network smart card 04925
• Some aspect of this communication uses direct communication between the network smart card 101 and the remote entity 127, for example, for the purpose of communicating some information that is stored on the network smart card 101 to the remote entity 127.
• a network-connected electronic-device 101 ' is a network smart card having a credit card form factor and which is connected to the Internet 125 via a host computer 103'.
• a network smart card 101 or 101' is a smart card that is capable to act as an autonomous Internet node.
• Network smart cards are described in co-pending patent application 10/848,738 "SECURE NETWORKING USING A RESOURCE- CONSTRAINED DEVICE", filed on May 19, 2004, the entire disclosure of which is incorporated herein by reference.
• a network smart card 101 implements Internet protocols (TCP/IP) and security protocols (SSL/TLS) built into the card and may implement other communications protocols as described herein below.
• the network smart card 101 can establish and maintain secure Internet connections with other Internet nodes.
• the network smart card 101 does not depend on a proxy on the host to enable Internet communications. More over, the network smart card 101 does not require local or remote Internet clients or servers to be modified in order to communicate with the smart card.
• a network-enabled electronic-device may be a computer 101".
• network- enabled electronic-device refers to any electronic device that is connected via a network to other electronic-devices and is capable of communicating electronically with such other devices.
• reference numeral 101 is used to refer to any such device and not specifically to any one such device.
• the network-connected electronic device may be a network smart card, e.g., smart card 101'.
• Network smart cards which are described in co-pending patent application 10/848,738 "SECURE NETWORKING USING A RESOURCE- CONSTRAINED DEVICE", filed on May 19, 2004, the entire disclosure of which is incorporated herein by reference, combine the functionality of traditional smart cards with the capability of acting as autonomous network nodes by implementing a communications protocol stack used for network communication.
• the host computer 103' may be the attacking computer, for example, as a reflector or by having some malware installed thereon.
• FIG. 2 is a schematic illustration of an exemplary architecture of the hardware of a network-connected electronic device 101 that may be used in conjunction with the invention.
• the network-connected electronic device 101 has a central processing unit 203, a read-only memory (ROM) 205, a random access memory (RAM) 207, a non- volatile memory (NVM) 209, and a communications interface 211 for receiving input and placing output to a computer network, e.g., the Internet, to which the network-connected electronic device 101 is connected, either directly or via intermediary devices, such as a host computer 103'.
• a computer network e.g., the Internet
• intermediary devices such as a host computer 103'.
• These various components are connected to one another, for example, by bus 213.
• a communications module 321 (introduced in Figure 3 below and described herein below in conjunction with Figure 3 and other figures herein), as well as other software modules described herein below, would be stored on the resource-constrained device 101 in the ROM 205.
• the software modules stored in ROM 205 would be stored in a flash memory or other types of non- volatile memory.
• the invention is described using the ROM example. However, that should not be construed as a limitation on the scope of the invention and wherever ROM is used, flash memory and other types of non- volatile memory can be substituted as an alternative.
• the ROM 205 would also contain some type of operating system, e.g., a Java Virtual Machine. Alternatively, the communications module 321 would be part of the operating system. During operation, the CPU 203 operates according to instructions in the various software modules stored in the ROM 205 or NVM 209.
• some type of operating system e.g., a Java Virtual Machine.
• the communications module 321 would be part of the operating system.
• the CPU 203 operates according to instructions in the various software modules stored in the ROM 205 or NVM 209.
• the CPU 203 operates according to the instructions in the communications module 321 to perform the various operations of the communications module 321 described herein below.
• Figure 3 is a schematic illustration of the software architecture for a resource constrained device 301 and a host computer 303.
• the resource constrained device 301 may be the SIM card 101 or a network smart card 101'
• the handset 303 may be the handset 103 or the host computer 103'.
• the host computer 303 has loaded thereon several network applications 305a, 305b, and 305c. (Note: In the case of a handset 103, the handset physical architecture is much like that of a computer. Thus, the handset 103 has a memory and 6 004925
• the memory may be composed of RAM 5 ROM, EEPROM, etc.
• the memory contains the software modules that control the behavior of the processor.
• the various software modules illustrated in Figure 3 as being part of host computer 303 are usually stored in some non- volatile memory of the mobile device and loaded into the RAM while being executed. From there the software module instructions control the behavior of the processor and causes the mobile device to do certain things, e.g., establish network connections.) Examples of such applications include web browser, and network contacts list application.
• an application 305 a may be used to access the resource constrained device 301, or more accurately, communicate with a web server executing on the resource constrained device 301, e.g., SIM card network application 307a.
• the host computer 303 and the resource constrained device 301 communicate over several layers of communication protocols.
• these layers may be represented by several communicating software modules, e.g., a TCP/IP Module 317 for handling communications at the TCP/IP level on host computer 303 and a corresponding TCP/IP Module 327 on the resource-constrained device 301, PPP modules 318 and 329 for handling communications at the PPP level, and a Peer I/O Server module 315 on the host computer 303 and a corresponding Peer I/O client module 325 on resource-constrained device 301 for communicating according to the Peer I/O protocol.
• the operation of the Peer I/O client module 325 and Peer I/O server module 315 are described in greater detail herein below.
• the resource-constrained device 301 and host computer 303 are also connected as a hardware layer, e.g., through a USB or wireless connection, and accordingly have hardware communications modules 318 and 319 for managing hardware level communication.
• the host computer 303 may establish connection with the outside data network and may support several applications 305a-c.
• the application programs on the host computer use a communications module 311 to establish connections to outside network and to communicate with applications 307a-c on the resource constrained device 301.
• the Peer I/O implementation is resident on both the host 303 and the device 301.
• the Peer I/O provides services to forward messages between the device 301 and the network 117.
• this service module is referred to as the Peer I/O Server 315.
• the device 301 contains a Peer I/O client 325 that is located above the low-level half-duplex serial communication protocol 318 operating in a command/response mode and below the full duplex protocols, such as PPP 329.
• PPP 329 full duplex protocols
• Peer I/O can carry messages to and from both directions. For example, we can use Peer I/O 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 over a half-duplex serial command/response link is transparent to the upper level applications and communications protocols on both the resource-constrained device 301, the host 303 and on other network nodes that may be in communication with the resource-constrained device 301.
• Peer I/O server 315 When a computer over the network (or simply to say “the network”) sends a message to the device, Peer I/O server 315 forwards the message by sending one or more commands of the command/response communication protocol containing the message to the device 301. To enable the device 301 to send a message to the network 117 whenever it needs to send, the Peer I/O server 315 polls the device 301 regularly. When the device has a message, the Peer I/O server 315 issues one or more commands to get the device's message and forward it to the network.
• Peer I/O server 315 The operation of the device 301 and 303 to effect the communication over the half-duplex serial command/response link that connect these devices is controlled by the Peer I/O server 315 and the 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 Machines enable the communication to performed using upper level messages of any length without using an explicit fragmentation and assembly mechanism.
• 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 for the host to check with the device to see if the device has data to send.
• the implementation of these commands is protocol dependent.
• the Poll command may be implemented as Put Packet command with no data. In this case, the Peer I/O protocol only requires two commands: Put Packet and Get Packet.
• the Peer I/O command type may be represented by one byte or two bits, or even one bit, depending on the underlying protocol.
• the Put Packet command typically has the following format:
• Length is the length of the data to send from the host to the device.
• the device After receiving the Put Packet command from the host, the device gets the data and returns a status.
• the Get Packet command typically has the following format where the Length is the length of the data to get from the device to the host.
• the device After receiving the Get Packet Command from the host, the device sends data of the required length to the host and then sends a status.
• the Poll command typically does not require a parameter.
• the device After receiving a Poll command from the host, the device sends a status. [0062] The status returned from the device to the host may represent several things including the following:
• the polling interval may be infinite, which means "do not poll, I am waiting for data.”
• the underlying protocol typically limits the length of the data within a packet. For example, some protocol limits the data to 256 bytes.
• the Peer I/O protocol respects the limit of the underlying protocol. It enables to send and to 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 packets.
• This section describes some typical operations of the Peer I/O protocol.
• the Peer I/O server 315 issues a Put Packet command to the device.
• the device When the device wants to send a data to the network, it has to wait for its opportunity.
• the Peer I/O Server 315 regularly polls to give the device opportunities to send.
• the server issues a POLL command.
• the device After receiving a command from the Peer I/O Server 315 , if the device has no data to send, it sends a status indicating so. If the device has data to send, it sends the "has data" status and the length of data that the device intends to send.
• the Peer I/O server 315 When the Peer I/O server 315 receives the status indicating that the device has data to send, it issues a Get Packet command.
• the device responds with a response containing data.
• the Peer I/O Server 315 can issue another Get Packet command.
• the Peer I/O Server 315 in the host polls the device regularly to see if the device has data to send. This polling is controlled by a polling interval, which may be infinite. Such controlled polling reduces the power consumption that would occur if the device 301 were continuously polled by the host 303.
• the Peer I/O defines a new return status that allows specifying 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 closely as possible to the polling interval.
• the polling interval can also be infinite.
• the device may specify infinite polling interval when it is waiting to receive data. In this case, the Peer I/O server 315 will not poll the device and only contact the device when there is data available for the device. For example, if the device is a web server, when it waits for a client connection, the device may set the polling interval to infinite.
• This new addition to the Peer I/O is very important for mobile applications; for example when the host is a small mobile device running with a battery and the device consumes the power supplied by the host.
• the return status may be represented by two octets.
• the most significant 4 bits represent "has data” or "no data".
• the rest of the bits may represent the length of the data.
• For "no data” case if all the rest of the bits are O's, it means, "use current polling interval", which may be the default polling. If all the rest of the bits are l's, it means, "do not poll”. Otherwise, the next two bits represent the unit of the polling interval, such as second, minute, or hour. The rest of the ten bits represent the polling interval.
• FIG. 9 is a schematic illustration of the finite state machine 901 that controls the behavior of the Peer I/O server 315.
• the finite state machine (FSM) 901 has five states:
• the Peer I/O server 315 starts by polling the Peer I/O client 325.
• the client 325 may indicate whether it has data transmit and a 2006/004925
• transition 401 Whenever the Peer I/O client 325 returns a status (cd), transition 401 , that is an indication that the client 325 has data to send.
• the Peer I/O server 315 gets data from the client 325 and forward the data to the network 117.
• the server 325 keeps getting data from client 315, by issuing Get_Packet actions, state 905, and forward data to the network as long as client 315 returns status cd, transition 403.
• the Peer I/O server 315 checks with the network, transition 407 to state 907. When the network has data, Peer I/O server 315 gets data from the network and forwards the data to the client 325, transition 409 to state 909. If the network has no data, nnd, Peer I/O server 315 may or may not poll the client 325 depending on the polling interval setting.
• the Peer I/O server 315 polls the client 325, transition 411 to state 903; otherwise, i.e., if the polling interval has not been reached (Itimeout), the server 315 remain at the "checking network" state 907, transition 413.
• Figure 5 is a schematic illustration of the 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:
• the device 301 operates a Peer I/O client 325, which starts at the initial state 503.
• the upper layer e.g., applications 307a-c communicating through the TCP/IP module 327, may either request to write or to read.
• the application 307 on the device 301 sends the first message to initiate connection (the Peer I/O protocol is independent of whether it is the device or host to initiate the connection).
• the Peer I/O client 325 leaves its "initial" state 503 and goes to "ready write” state 507 when the upper layer issues a write instruction, transition 511.
• the Peer I/O client 325 waits for the message from Peer I/O server 315.
• the server 315 starts by polling the client 325.
• the client 325 sends status cd, transition 513, with the number of bytes to be sent, and remains in the "ready write” state 507.
• the server 315 issues a Get Packet command
• the client 325 sends the data and moves to "wait upper" state 505 where it waits for upper layer instructions, transition 514.
• the client 325 sends status cd to Peer I/O server 315 and moves to "ready write” state 507, transition 516.
• the client 325 sends status end to Peer I/O server 315 and moves to "ready read” state 509, transition 517.
• the client 325 may also transition from the "initial” state 503 to the "ready read” state 509 if it receives a "read” instruction from the upper layer while the client 325 is in the "initial” state 503, transition 521.
• the client 325 waits for the Peer I/O server 315 command.
• the server 315 polls, the client 325 sends another end and remains in "ready read” state 509, transition 519. If the server 315 issues Put Packet command, the client 325 gets the data and moves to "wait upper” state 505, transition 515.
• the Peer I/O protocol has many applications.
• a first example is connecting a network smart card to the Internet via a host computer.
• a smart card is a small card that contains a microprocessor chip.
• ISO defines two form factors for smart cards: credit card-shaped cards and SIM 006/004925
• Smart cards are secure, portable and tamper resistant. They have served security purposes for a wide range of applications, including mobile communications (SIM card in cell phones), banking, physical access control, network access control, transportation, digital identity, and so on. Unfortunately, smart card communication standards do not match with those of mainstream computing, which has limited the success of smart cards.
• the current smartcard standard ISO 7816 (ISO 14443 for contact-less smart cards) specifies a half-duplex serial command/response communication protocol, while standard Internet protocols, such as PPP, IP, and TCP, operate in a full-duplex and peer-to-peer mode. Applying the Peer I/O, enables the current smartcard compliant with ISO 7816 (or ISO 14443) standard to become an Internet node. This section describes the implementation of the Peer I/O using ISO 7816 commands.
• FIG. 6 is an illustration of a first alternative for connecting an infrastructureless network smart card 301 according to the invention to a network 117.
• 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 acts as a router for routing Internet communications to and from the card 301.
• the computer 303 has a first IP address for its connection to the network 117 and a second IP address for connections to the infrastructureless network smart card 301.
• the third IP address may be either assigned to the card 301 or allocated dynamically. 2006/004925
• the computer 303 has Remote Access Server (RAS) that provides Internet service to other computers connected to this computer.
• RAS Remote Access Server
• the smartcard 301 would have full-duplex serial I/O, then just like other full-duplex serial device, the smart card with TCP/IP/PPP could establish Internet connection via RAS without loading any additional software on the computer 303.
• smartcards standard specifies half-duplex serial I/O.
• Internet protocols are peer to peer, meaning a node can talk at wish, while ISO 7816 and ISO 14443 protocols specify command/response operation where the smartcard only respond to the command issued by the terminal.
• the Peer I/O protocol implemented according to the invention solve both of these protocol mismatch problems.
• the Peer I/O implementation according to the invention exists as cooperating communications modules on the host computer 303 (or the reader 302) and in the smart card 301.
• the host computer (or the reader) contains the Peer I/O Server 315 that provides services to forward messages between the card and the Remote Access Server (RAS) on the host.
• the card contains Peer I/O client that sits above ISO 7816 and below other protocols, such as PPP.
• the Peer I/O Server 315 forwards the message by sending one or more APDU commands containing the message to the card. To enable the card to send a message to RAS, the Peer I/O server 315 polls the card regularly according to the polling interval.
• FIG. 7 is a high-level schematic diagram of the communications protocol stacks a host computer 303 and a network smart card 301 implementing the Peer I/O protocol.
• a Peer I/O module resides in both the host computer 303 (or reader 302) and in the card 301.
• the protocol stack on the host PC side 303, a Peer I/O server module 315 implements the Peer I/O protocol layer and provides services to forward messages between the card 301 and a Remote Access Server (RAS) 701 on the host computer 303.
• RAS Remote Access Server
• the protocol stack contains a Peer I/O protocol layer 325 that sits above APDU 807 and below other protocols, such as PPP 329.
• APDU provides the communications between the host 303 and the card 301.
• the Peer I/O protocol is independent of the Internet protocol it carries. From an upper layer protocol point of view, Peer I/O can carry messages to and from both directions. For example, Peer I/O can be used to carry PPP frames or Ethernet frames or IP datagrams. Peer I/O uses APDU to carry messages, such as PPP frames, Ethernet frames or IP datagrams.
• the following description of Peer I/O uses RAS and PPP as an example. In this case, the Peer I/O uses APDU to carry PPP frames.
• the Peer I/O server 315 forwards the message by sending one or more APDU commands containing the message to the card 301.
• the Peer I/O server 315 polls the card 301 regularly as discussed herein above. Finite State Machines, described in greater detail below, of the Peer I/O server 315 and the Peer I/O client 325 define a mechanism to forward messages of any length without using an explicit fragmentation and assembly mechanism.
• Peer I/O Protocol Format [0102] The following defines one implementation of Peer I/O as built on the ISO 7816 communications protocol. Peer I/O implementation is not limited to the following defined class, instruction, and status words set.
• Three instructions are defined for this Peer I/O class, namely, POLL, GET_PACKET, and PUT_PACKET.
• the Peer I/O server 315 uses POLL to poll the card to see if the card wants to send
• the Peer I/O protocol does not have its own protocol data unit. It uses APDU directly.
• a Peer I/O command APDU has the following format:
• the instruction INS can be one of the following:
• PUT_PACKET ( OxEA) Length is the number of bytes of Data sending to
• the Length is one byte, so the maximum data length is 256 bytes.
• a response APDU has the following format:
• the ACK represents the acknowledgement from the card for receiving the
• the ACK is the INC code of the received command.
• the status of the process on the card side is represented by SWl and SW2
• response status can be the following:
• READY-WRITExx e.g.,6Cxx: xx represents the number of bytes that the card is ready to send.
• NO- DATA e.g., 9000
• Peer I/O Server 315 issues a PUT PACKET command to the card.
• the APDU contains the data.
• the card When the card wants to send a data to RAS, it has to wait for its opportunity.
• the Peer I/O Server 315 regularly polls to give the card opportunities to send.
• the server issues a POLL command.
• the card After receiving a command APDU from the Peer I/O server 315 , the card responds with an ACK first. If the card has no data to send, it sets SWl SW2 as NO-
• DATA (e.g., 90 00).
• the card If the card has data to send, it sets SWl SW2 as ⁇ Cxx, where xx is the
• the card responds with a response APDU containing data.
• the Peer I/O server 315 can issue another
• FIGS 8 and 9 are schematic illustrations of two alternative implementations of the peer-to-peer communications system according to the invention on a smart card system.
• Figure 8 is a schematic illustration of the components for implementing communication between a smart card and a network wherein the smart card communicates to a host computer using a serial connection having half-duplex serial I/O.
• the smart card 301 connects to the host computer 303 through a reader 302.
• the driver of the reader implements the Peer I/O server 315.
• the composite driver behaves as a (virtual) serial port from the perspective of the host computer 303.
• a normal RAS connection to the virtual serial port enables the network connection to the smart card 301.
• the Peer I/O server 315 may also be implemented in hardware in the smart card reader.
• Figure 9 is a schematic illustration of the components for implementing communication between a smart card and a network wherein the smart card communicates to a hardware interface device over a half-duplex serial connection and the interface communicates to the host computer using a full-duplex connection.
• the reader 302 connects to the host computer 303 via serial connection or USB connection. (With USB connection, USB/serial conversions are need in the reader and in the host computer.) Again, a normal RAS connection to the serial port enables the network connection to the smart card 301.
• MMC MultiMediaCard
• MMC MultiMediaCards
• MultiMediaCards are small (24mm x 32mm or 18mm x 1.4mm), removable, solid-state memory cards for mobile applications, such as cell phones, digital cameras, MP-3 music players, and PDAs.
• the storage capacity of a MMC is up to 1 Gbyte of data.
• High speed MMC can transfer data up to 52 Mbits/second.
• MMCs use flash technology for read/write applications and ROM or flash technology for read only applications.
• An MMC has a seven-pin serial interface, which has three communication lines (command, clock and data) and four supply lines. The MMC initialization and data transfer are based on the MMC bus protocol. Each message uses one of the three tokens: Command, Response and Data.
• a command token starts an operation, which is sent from the host to one or more cards.
• the response token is sent from the addressed card or cards to the host.
• the data token can go either way. All bits on the data and command lines are transferred synchronously with the clock.
• the Secure MultiMediaCard adds smart card security features into the MMC for content protection and e-commerce. It has a tamper resistant module for secure storage and does encryptions and authentication within the card.
• Infineon Technologies uses its smart card hardware technology in its Secure MMC.
• the Secure MMC is fully compatible with standard MMC.
• the Peer I/O protocol (described in greater detail below) is implemented in a Peer I/O client 325 using the MMC bus protocol to carry Internet protocol data, for example, PPP frames.
• the SPI is another communication interface to MMC, in addition to MMC bus.
• MMC cards allow selecting MMC or SPI mode. Therefore, the methods presented above in the section describing use of SPI in a network smart card apply to Secure MMC as well.
• the Secure MMC may also use other multimedia transport protocols to communicate with the host or the network.
• Figure 10 illustrates one example configuration for making Secure MMC as an Internet node. Other examples include replacing PPP and Peer I/O by other link layer protocols and replacing TCP by other transport protocols, such as UDP.
• the Near Field Communication is a wireless interface and protocol. It is targeted towards the consumer electronics, which are moving from isolated devices to networked devices. The NFC devices communicate by getting close to each other without requiring the user to configure the network.
• the NFC interface operates in the unregulated RF band of 13.56 MHz. The communication is half-duplex. The operating distances are about 0 - 20 cm. (NFC is described in "Near Field Communication - white paper," ECMA International, Ecma/TC32-TGl 9/2004/1)
• the NFC protocol distinguishes between the Initiator and the Target.
• the Initiator device initiates and controls the data exchange.
• the Target device answers the request from the Initiator.
• the NFC protocol has two operation modes: Active mode and Passive mode. In the Active mode, both devices generate their own RF field to cany data. In the Passive mode, only the Initiator generates the RF field, which both the Initiator and Target devices use to transfer the data.
• the NFC devices set the initial communication speed at 106, 212, or 424 kbit/s.
• the Active communication mode can reach much higher bit rate, 6 Mbit/s ("Near Field Communication- Interface and Protocol (NFCIP-I)", Standard ECMA-340, December 2002).
• the NFC is a very short-range wireless protocol. It is intuitively secure, as two NFC devices have to be very close to each other in order to communicate.
• the Passive mode of communication is an important feature of NFC. Battery-powered mobile devices, such as a mobile phone, or mobile devices without power source can communicate with other NFC devices without having to generating RF field.
• the NFC devices exchange data using NFC's data exchange protocol (DEP).
• DEP NFC's data exchange protocol
• the DEP is a Request/Response protocol.
• the Initiator sends a Request and the Target transmits a Response.
• the NFC devices that do not generate RF field always operate in the Passive mode of communication and are Target devices. They are in a similar situation as the standard ISO 7816 or ISO 14443 smart cards.
• Peer I/O Similar to the techniques described herein above we can implement Peer I/O using DEP. For example, we can use the undefined bit setting of the DEP protocol header to define the Peer I/O commands.
• Peer I/O will enable such device to behave as a network peer, that is, to become an active device.
• the Dallas Semiconductor's iButton is a computer chip enclosed in a 16mm stainless steel can iButton, http://www.ibutton.com.
• the iButton can be attached to a key fob, ring, watch, or other personal items.
• the applications of the iButton include access control to buildings and computers.
• the iButton communicates with the host computer through a reader/writer device.
• the communications use a 1-wire protocol, with which data transfers are bit- sequential and half-duplex.
• the iButton is considered as a slave while the host with a reader/writer is a master.
• the Peer I/O can be implemented using the iButton' s 1-wire protocol. The implementation will enable the iButton to become an active peer and to initiate communications.
• Peer I/O implementation may enable such devices to support networking protocols and to be active peers in a network.
• the peer-to-peer communications method and system provides efficient and flexible peer-to-peer communication allowing a resource-constrained device to communicate as a network peer.
• An electronic device incorporating logic implementing or operating according to the method of the invention may, even though designed to communicate to a host device over a half-duplex serial command/response communications link, appear to be communicate in an asynchronous full-duplex manner.
• the system and method for peer-to-peer communication according to the invention adds minimal power consumption to the host and resource-constrained devices and may therefore be favorably deployed in small portable devices with limited power supply capabilities.
• the system and method of peer-to-peer communication according to the invention provides several advantages over existing communications systems.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Communication Control (AREA)
• Mobile Radio Communication Systems (AREA)
• Computer And Data Communications (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=36501861

Family Applications (1)

Country Status (4)

Families Citing this family (10)

Family Cites Families (5)

• 2006
  • 2006-02-11 KR KR1020077017106A patent/KR101172930B1/ko active IP Right Grant
  • 2006-02-11 EP EP06734870A patent/EP1864470A1/en not_active Withdrawn
  • 2006-02-11 JP JP2007555292A patent/JP4869259B2/ja active Active
  • 2006-02-11 WO PCT/US2006/004925 patent/WO2006086729A1/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events