Patent Application
20080163352
The invention relates to a method for loading a piece of software into a smart card.
More particularly, it applies to loading a piece of software known as an “applet”. This involves an application written in JAVA language (registered trademark). These applications, which in general are not very voluminous, are independent of the architectures of the systems in which they are implanted. Accordingly, they can run on any information processing system, as long as the system employs the concept known as “JAVA Virtual Machine”. An application written in JAVA language is in general translated into an intermediate language known as byte code. The aforementioned JAVA Virtual Machine constitutes an interpreter of this byte code, in such a way as to be executed directly in target system that is the host of said virtual machine.
In general, the system architectures on which such applications run are of the type known as a client-server. In this case, the term “servlet” is also used for an application stored on a server system, and “applet” is used for an application stored on a client system. Below, the term “applet” will be used generally.
Pieces of software in the form of applets, as has just been recalled, can be stored in a nonvolatile memory on a smart card, in the same way as any other application, as long as the quantity of code is not overly voluminous.
The method according to the invention more particularly relates to a terminal or user station provided with a smart card reader.
Within the scope of the invention, the term “terminal” must be understood in a general sense. The aforementioned terminal can in particular comprise a personal computer operating under various operating systems, such as Windows or UNIX (both of which are registered trademarks). It can also comprise a work station, a portable computer, or a dedicated card terminal.
In the current state of the art, loading an applet on a smart card (also called teleloading) is done thanks to two specific programs. These programs are generally known by the terms off-loader for the first one and in-loader for the second. The off-loader program is executed in the terminal, and the in-loader program is executed in the smart card. The loading programs off-loader and in-loader communicate with one another through a link standardized under ISO 7816-3, which is a protocol universally reserved for communications between a smart card and its host terminal. This protocol employs a set of exchanges, which are generally proprietary (commands of a type known as APDU, which will be explained hereinafter) in order to accomplish the loading of an applet.
The terminal 1 stores a first specific loading program (off-loader) OL. It communicates with a smart card 2 via a smart card reader 3. The transmissions are done by a standardized communication protocol making use of aforementioned commands, and this protocol will be described in detail hereinafter.
The smart card 2 for its part stores a second specific loading program (in-loader) IL.
A first disadvantage of this method is that the programs IL and OL must be matched so that they can communicate with one another. It follows that if they are of different origins, they are a priori incompatible. This characteristic is linked with the set of commands to be used.
A second disadvantage is due to the fact that communications are done by the aforementioned protocol ISO 7816. This protocol requires physical proximity between the programs OL and IL. It follows that the program OL must generally be executed directly in the terminal 1, and not in another terminal or a remote server, for example.
Given the spectacular development of the internet, an ever-increasing number of terminals are connected to this network, especially so as to be capable of linkage with remote web-type servers. It would accordingly be valuable for instance to be able to store the off-loader part OL of the applet loading program in a webserver connected to this network. The applets to be loaded on one or more smart cards can also be stored in this server or in a plurality of other servers of this type.
In the state of the art, this mode of operation meets with a dual impossibility. The first has already been mentioned: The standard reserved for communications between the terminal and the smart card a priori imposes physical proximity between the locations of the off-loader and in-loader programs OL and IL, respectively.
Second, the transmissions between two systems, such as a terminal and remote server, via the internet makes use of internet-type protocols. In the state of the art, it is not possible to achieve direct communications between a smart card and the internet, as will also be explained.
Within the scope of the invention, the term “internet network” or internet includes not only the internet per se but private business networks or the like of the type known as “intranet” and networks that extend them to the outside, of the type known as “extranet”, and in general any network in which data exchanges are done by a protocol of the internet type. Below, such a network will be referred to generically as an internet network, or simply “internet”.
First, the general architecture of a smart card-based applications system will be reviewed briefly, with reference to
A smart card-based applications system can generally include the following main elements:
The terminal 1 naturally includes all the circuits and devices necessary for its proper functioning, which have not been shown for the sake of simplifying the drawing: a CPU, random access and read-only memories, magnetic disk mass memory, disk drive and/or CD-ROM drive, and so forth.
Typically, the terminal 1 is also connected to conventional peripherals, either integrated or not, such as a display screen 5, a keyboard 6a and a mouse 6b, and so forth.
The terminal 1 can be put into communication with servers or any information processing systems connected to the network RI, of which a single server 4 is shown in
Typically, communications over the networks are done in accordance with protocols that meet standards including a plurality of superimposed software layers. In the case of an internet-type network RI, the communications are done according to protocols specific to this type of communications, which will be described in detail hereinafter, but which also include a plurality of software layers. The communication protocol is selected as a function of the particular application contemplated, such as looking up web pages, transferring files, electronic mail (or e-mail), forms, news, etc.
The software architecture of the system including a terminal, a smart card reader and a smart card, is shown schematically in
In
An application Ai in the smart card 2 (
When the smart card 2 includes a plurality of distinct applications, as illustrated by
The selection of a particular application Ai is obtained with the aid of an APDU of the selection type (“SELECT”). Once this choice has been made, the APDUs that follow are routed through this application. A new “APDU SELECT” causes the current application to be abandoned so that another one is then chosen. The software manager subset of the APDUs 201 makes it possible to choose a particular application Ai in the smart card 2, to memorize the application thus chosen, and to transmit and/or receive APDUs to and from this application.
To summarize what has just been described, the selection of an application Ai and dialog with it are done by exchanges of APDU orders. Let it be assumed that the applications Ai are conventional applications, hereinafter called GCAs (for Generic Card Application).
This mode of operation requires that the programs OL and IL be matched, so that the APDU orders exchanged can be compatible and understood by these two applications.
Given the above review, it should be noted that the smart card 2 cannot communicate directly with standard commercial navigators except by modifying their code.
Furthermore and above all, current smart cards, which moreover meet the standards described above, have a hardware and software configuration that no longer allows them to communicate directly with the internet. In particular, they cannot receive and transmit data packets by one or the other of the protocols used in this type of network. Hence it is necessary to provide an additional piece of software, implanted in the terminal 1, generally in the form known as a “plug-in”. This piece of software, which is identified by reference numeral 12 in
In a first characteristic of the invention, the two loading programs OL and IL are no longer dependent on one another. In other words, they no longer have to be matched to be compatible.
In a second characteristic of the invention, the OL portion of the loading programs no longer has to be necessarily stored in the terminal, that is, in physical proximity with the second portion IL. On the contrary, the program OL can be stored in a remote server connected to the terminal via a network of the internet type.
To do so, and in a first characteristic of the invention, the smart card behaves like a web-type server-client with regard to the terminal with which it is associated.
To attain this object, a specific communication protocol layer is provided in the smart card and its counterpart in the terminal. The term “specific” must be understood to mean specific to the method of the invention. In fact, these communication layers, called specific communication layers, are non-specialized, regardless of the application in question. They act only in the process of bidirectional data exchanges between the smart card and the terminal on the one hand, and the smart card and the network, on the other.
The specific communication software layer, known as “intelligent agents”, make it possible in particular to convert protocols. The intelligent agents will hereinafter be called simply “agents”. There are matched agents in the specific communication layers assigned to the terminal and the smart card, respectively. By the method of the invention, sessions between matched agents are established.
In another characteristic, the method of the invention makes it possible to activate applications of a conventional type, that is, of the aforementioned CGA type, that are located in a smart card without having to modify them in any way.
To do so, one or more particular intelligent agents called script translators are provided, which receive requests from a navigator and translate them into APDU orders that can be understood by the CGA application. In this way, a function similar to that also known as “CGI” in conventional webservers is implanted into the smart card. This function makes it possible to implement an application in the smart card using an internet protocol of the HTTP type.
Loading an applet in the smart card can be done by this CGI, or Common Gateway Interface. The portion IL of the loading program is considered to be a command script, which will be called “cgi-script”, attached to the webserver function offered by the smart card. These exchanges between the programs OL and IL can take place with the aid of conventional forms in HTML.
While preserving the aforementioned ISO standards for communications between the terminal and the smart card via the smart card reader, the method according to the invention enables exchanges between the portions of loading programs OL and IL by using the internet communication protocol TCP/IP, and the portion OL and the applets to be loaded can be stored locally or in a remote server.
Hence the main subject of the invention is a method for loading a piece of software into a smart card from a terminal connected to said smart card by way of a smart card reader enabling communications by a first predetermined protocol, said loading being effected by the implementation and cooperation of first and second loading programs, said second loading program being stored in said smart card, characterized in that it includes at least the following phases:
a) a first preliminary phase, consisting of implanting, in said smart card, a first piece of software, forming a specific communication protocol layer;
b) a second preliminary phase, consisting of implanting, in said terminal, a second piece of software, forming a specific communication protocol layer;
1) opening a first data exchange session between at least said terminal and said smart card, for the transmission
of a request so that said first loading program will retrieve loading parametrizing data furnished by said second loading program;
2) opening a second data exchange session between said smart card and at least said terminal, to transmit said loading parametrizing data to said first loading program, said parametrizing data including a reference to said instructions that are associated with said second loading program; and
3) opening a second data exchange session between said smart card and at least said terminal, and for submitting a loading file taking said loading parametrizing data into account, said file including data associated with said piece of software to be loaded; interpretation of said set of instructions associated with said second loading program, by implementation of said CGI function, in such a way as to generate a set of orders transmitted to said second loading program to execute this program and obtain said unloading of said piece of software.
The invention will now be described in more detail in conjunction with the accompanying drawings, in which:
In the following description, without in any way limiting the scope, the discussion will refer to the preferred application of the invention, unless otherwise noted; that is, it refers to the case of a terminal connected to one or more remote servers via the internet.
Before the method of activating applications located in a smart card according to the invention is described and an architecture for implementing it is described in detail with reference to
The architecture of communication networks is described by various layers. By way of example, the OSI standard (for Open System Interconnection) defined by the ISO includes seven layers, which range from what are known as lower layers (such as the “physical” layer, which involves the physical transmission substrate) to what are known as high, or upper, layers (such as the “application” layer), passing through intermediate layers, especially the “transport” layer. A given layer offers its services to the layer that is immediately above it, and requests other services, via suitable interfaces, from the layer that is immediately below it. The layers communicate with the aid of primitives. They can also communicate with layers of the same level. In certain architectures, various layers may not be present.
In an environment of the internet type, the layers are five in number, and more precisely, ranging from the highest to the lowest layer, they are: the application layer (“http”, “ftp”, “e-mail”, etc.), the transport layer (“TCP”), the network addressing layer (“IP”), the data link layer (“PPP”, “Slip”, etc.), and the physical layer.
Turning to
The terminal 1 includes circuits 11 for access to the network RI, the circuits being constituted by a modem, for example. These circuits include the lower software layers C1 and C2, which correspond to the physical and data link layers.
Also shown are the upper layers C3 and C4, which correspond to the network addressing (IP, in the case of the internet) and transport (TCP) layers. The upper application layer (“http”, “ftp”, “e-mail”, etc.) has not been shown.
The interface between the lower layers C1 and C2 and the upper layers C3 and C4 is made up of a software layer, generally called a “low driver layer”. The upper layers C3 and C4 rest on this interface and are implemented by way of specific function libraries or network libraries 14, with which they correspond. In the case of the internet, TCP/IP is implemented by means of what are known as “socket” libraries.
This organization enables a navigator 10 to make requests of a server 4 to consult web pages (“HTTP” protocol) to transport files (“FTP” protocol) or to send electronic mail (“e-mail” protocol), in an entirely classical fashion.
The terminal 1 also includes a card reader 3, which may or may not be integrated. For communication with the smart card 2a, the card reader 3 also includes two low layers CC1 (physical layer) and CC2 (data link layer), which play a role similar to the layers C1 and C2. The software interfaces with the layers CC1 and CC2 are described for example by the PC/SC specification (part 6, service provider). The layers themselves, CC1 and CC2, are described in particular by ISO
standards 7816-1 through 7816-4, as has been noted above.
An additional software layer 16 forms an interface between the application layers (not shown) and the lower layers CC1 and CC2. The main function assigned to this layer 16 is that of multiplexing/demultiplexing.
Communications with the smart card 2a are done by a paradigm similar to that used to manipulate files in an operating system of the UNIX type (UNIX is a registered trademark): OPEN, READ, WRITE, CLOSE, etc.
A similar organization is found in the smart card 2a, that is, the presence of two low layers, CCa1 (physical layer) and CCa2 (data link layer), as well as an interface layer 26a, which is entirely similar to the layer 16.
In a first characteristic of the invention, two specific protocol layers 13 and 23a, respectively, are provided on one hand and other, that is, in the terminal and in the smart card 2a.
In the terminal 1, the specific layer 13 interfaces with “low driver layers” 15, libraries 14 of network layers C3 and C4, and protocol layers for the card reader 3, that is, the lower layers CC1 and CC2, via the multiplexing layer 16. The specific layer 13 enables the transfer of network packets from and to the smart card 2a. It also adapts the existing applications, such as the internet navigator 10, e-mail, etc., for uses that employ the smart card 2a.
In the smart card 2a, quite a similar organization is found, with an additional instance of the specific layer 23a, which is the counterpart of the layer 13.
More precisely, the specific layers 13 and 23a are subdivided into three main software elements:
For the sake of simplicity, these intelligent agents will be called simply agents hereinafter, as noted above.
In the terminal 1 and the smart card 2a, a communication protocol stack is found between the two entities.
The layers at level two (data link layers) CC2 and CCa2 assure the exchange between the smart card 2a and the terminal 1. These layers are responsible for detecting and as needed correcting transmission errors. Various protocols can be used, and by way of a non-exhaustive example, the following:
Within the scope of the invention, the ISO 7816-3 protocol in block mode will preferably be used.
In a manner known per se, a certain number of primitives is assigned to each protocol layer; they enable the exchanges of data between layers of the same level and from one layer to the other. By way of example, the primitives assigned to the level 2 layer are of the “data request” (“Data.request”) and “send data” (“Data.response”) by the card as well as “confirmation of data” (“Data.confirm”), etc.
More specifically, the layers 13 and 23a are tasked with dialog between the smart card 2a and the host, that is, the terminal 1. These layers enable the exchange of information between a user (not shown) of the terminal 1 and the smart card 2a, for example by way of scrolling menus in the form of hypertext in the HTML format. They also allow the installation of a configuration adapted for the transmission and/or reception of data packets.
As indicated above, the layers include three distinct entities.
The first layer 130 or 230a essentially comprises a software multiplexer. It enables the exchange of information between the smart card 2a and the host terminal 1, in the form of protocol data units. It plays a role similar to that of a data packet switcher. These units are sent or received via the layer at level 2 (data link layer). This particular communication protocol makes it possible to put at least one pair of agents into communication. The first agent of each pair, 132, is located in the layer 13 of the terminal 1, while the second agent, 232a, is located in the layer 23a in the smart card 2a. A link between two agents is associated with a session that will be called “S-Agent”. A session is a bidirectional data exchange between these two agents. If one or the other of the layers 13 and 23a includes a plurality of agents, then the agents of the same layer can also establish sessions between them and/or with the modules 131 and 231a that constitute the particular agents.
More precisely, an agent is an autonomous software entity, which can embody all or some of the functions of layers at levels 3 and 4, depending on the configuration implemented by the terminal 1.
These agents are assigned particular properties or attributes. To define the concepts, and by way of non-limiting examples, the following six properties are assigned to the agents:
A particular agent is identified by a reference, such as a 16-bit integer (that is, an integer between zero and 65535). The most significant bit (b15=1) tells whether this reference is local (local communications with the smart card or the terminal) or remote (b15=0).
Two large categories of agents exist: the agents of the “server” type, which are identified by a fixed reference, and the agents of the “client” type, which are identified by a variable reference that can also be called ephemeral, issued by the configuration management module 131 or 231a.
The agents communicate with one another by way of entities called protocol data units or pdus, which include a target reference and a source reference. This particular pdu can also be called a “SmartTP pdu”, with reference to the currently used term “smart card”. In particular, the pdus utilize the references defined above.
A SmartTP pdu, or more simply pdu hereinafter, includes a source reference, a target reference, a set of bits comprising flags, which specify the nature of the pdu, and optional data:
A pdu that does not include data will be called a token.
The SmartTP entity controls the existence of the target agent and performs the commutation of a packet to it.
An agent session or “S-Agent” has three notable states, specifically:
The mechanism for establishing an “S-Agent” session is as follows:
Once a session is open, two agents exchange data via pdus.
The mechanism for closing a session is as follows:
The layers 130 and 230a manage tables (not shown) that contain the list of agents present, in the host terminal 1 and the smart card 2a.
In practical terms, the agents enable an exchange of data (in hypertext, for example), but also enable launching network transactions, authorizing communications between the smart card 2a and a remote server 4 (
The configuration management modules, 131 and 231a, respectively, are similar to particular agents. For example, the module 131 in the host terminal 1 in particular manages information relating to the configuration of this terminal (modes of operation), lists other agents present, and so forth. The module 231a in the smart card 2a has analogous functions. These two agents can be put into communication with one another in order to establish a session.
In practical terms, the smart card 2a is advantageously “addressed” by using a URL (for universal resource locator) that defines a feedback to the terminal 1 itself, rather than pointing to an external server. By way of example, the structure of this URL is typically as follows:
http://127.0.0.1:8080 (1)
in which 127.0.0.1 is the feedback IP address, and 8080 is the port number.
There are two stacks in the terminal, one communicating with the internet RI and the other with the smart card 2a. The first stack includes the devices 11 (
The APDU order manager 201a is also interfaced with one or more applications-level layers, which will simply be called applications. As has been noted, these applications Al . . . , Ai . . . , An, are application of a conventional type.
In summary, the client/webserver furnished by the smart card 2a can be embodied by association with the web agent 231a1 in the smart card and the network agent 132 in the terminal 1, and by implementing sessions between agents, as has been described.
The smart card 2a does indeed have the function of client/webserver. In addition, in a characteristic of the method of the invention, any conventional application Al through An of the GCA type mentioned above can be activated through this client/webserver, either via the web navigator 10 in the terminal 1 or via a remote navigator 4 located at any point in the internet RI, by implementing sessions between agents. According to the method of the invention, the applications Al through An do not have to be rewritten and are implemented as is.
In the context of the invention, all or some of the applications Al through An can comprise applets, which are initially loaded into a nonvolatile memory in the smart card 2 or, contrarily, are loaded by way of the two loading programs OL and IL, whose nature and possible storage links will be described in further detail hereinafter.
In a first aspect of the invention, the webserver function offered by the smart card includes a mechanism similar to the function known as CGI (Common Gateway Interface) implanted in convention webservers.
Before describing an example of architecture according to the invention that makes it possible to achieve a function of this type, even at the level of the smart card, it is useful to recall the principle characteristics of a CGI mode of operation.
CGI is a specification for implementing, from a webserver, applications written for the operating systems known as UNIX (registered trademark), DOS, or Windows (registered trademark). By way of example, for the UNIX operating system, the specification is CGI 1.1, and for the Windows 95 operating system, the specification is CGI 1.3.
Still by way of example, an http request for a URL address, of the following type:
“http://www.host.com/cgi-bin/xxx.cgi” (2),
in which “host” refers to a host system (generally remote), is interpreted by a webserver as the execution of a command script of the CGI type, named “xxx” and present in the “cgi-bin” directory of this host system. Although the name of the directory can a priori be arbitrary, by convention it is the name given to the directory that stores scripts of the CGI type. A script is a set of instructions of the host system operating system, whose final result is transmitted to the web navigator that sent the aforementioned request. Different languages can be used to write the script, such as PERL (registered trademark).
In practical terms, the request is typically posted on an information processing screen as a form comprising an HTML page. The HTML language makes it possible to translate a form into a URL address. The form includes one or more fields which may or may not be obligatory and which are filled by a user, using conventional input means: a keyboard for text, a mouse for putting an X in boxes to be checked, or buttons labelled “radio”, etc. The contents of the form (and as applicable information and instructions said to be “cached”) is sent to the webserver. The HTML code of the page describes the physical structure of the form (context, graphics, color, and any other attribute), and the structure of the data fields to be input (name, length, type of data, etc.).
The transmission can be done by two main types of format. A first format uses the method known as “POST”, and a second uses the method known as “GET”. Information on the format type is present in the code of the form page.
This mechanism cannot, however, be transposed directly to a smart card, even if the smart card has the client/webserver function in accordance with one of the characteristics of the invention.
An example of architecture that makes it possible to activate any application of convention type, via a webserver to the smart card, will now be described in conjunction with
Among the intelligent agents, in accordance with one of the aspects of the invention, particular intelligent agents are provided, which will hereinafter be called script translator agents, abbreviated STA. The script is then interpreted by one of the intelligent agents.
This translation can be done in various ways:
a) by the web agent 232a1 itself, which in this case is provided with a dual capacity;
b) by a unique script agent capable of translating all the scripts present in the smart card 2a;
c) by a dedicated script agent, which will be called “STAD” hereinafter (one agent per script); or
d) by an APDU agent 201a of the APDU order manager 201a, which in this case is provided with a dual capacity.
The APDU agent 201a is a component of the APDU order manager layer 201a. The latter is a layer capable of
centralizing all the APDU orders sent and/or received by the system, selecting from among applications Al to An, but also of offering an interface of the intelligent agent type. It is accordingly capable, according to the one of the characteristics of the invention, of communicating with all the intelligent agents (via sessions), whether the agents are located in the housing 6 or the smart card 2a.
In case c) above, a session is opened between the web agent 232a1 and one of the ATSD agents.
A script translator agent generates a set of APDU orders. A session is opened between the translator agent, such as the agent STAi and the APDU agent 2101a. The orders are then sent to the APDU agent 2101a. The APDU order manager 201a selects the CGA application Ai and sends it the APDU orders, which orders are translated and accordingly conventional, that it is capable of understanding. This application is then correctly activated without requiring modification or rewriting.
The responses from the application Ai are transmitted to the APDU order manager 201a, to the APDU agent 2010a, and again to the agent STAi (and more generally to the script translator agent).
The various pathways are symbolically represented in
The method according to the invention uses the two characteristics that have just been recalled: the function of the smart card as a webserver/client, including a “cgi” function. Loading an applet into the smart card is done in fact via the CGI interface offered by the smart card.
More precisely, in a characteristic of the invention, the portion IL of the loading program located in the smart card 2a comprises a script. For example, this is a script associated with the application Ai in
It should be noted that the data addressed to the web agent 232a1 are transported in a manner known per se in the form of APDU orders intended for the particular application comprising the “packet multiplexer” 230a. The APDU order manager 201a selects this application in a way quite similar to the other CGA-type applications Al through An that are present in the smart card 2a. In other words, the packet multiplexer 230a is viewed by the APDU order manager 201a like an ordinary CGA application.
The http request is analyzed by the web agent 232a1, which detects a reference to a particular directory, which by convention will hereinafter be called “cgi-smart” (by analogy with “cgi-bin”), on the one hand, and a particular application, which in the case of the example described is IL. The complete path is thus in this instance “cgi-smart/il”.
In a characteristic of the method of the invention, the above entity “il” designates a particular script associated with what is also a particular application (IL in this case).
A session is opened between the translator agent, for instance the agent STAi, and the APDU agent 2010a. The script translator agent STAi generates a set of APDU orders. The orders are sent to the APDU agent 2010a. The APDU order manager 201a selects the CGA application Ai (for example, the application IL) and sends it the APDU orders, which are translated and hence conventional, that it is capable of understanding. This application is then correctly activated.
The response from the application IL (Ai) is transmitted in the opposite direction to the APDU order manager 201a, to the APDU agent 2010a, and then again to the agent STAi (and more generally to the script translator agent).
The response, comprising a form in HTML language, takes the reverse path, by employing sessions between matched intelligent agents, so as to be retransmitted to the terminal 1, and optionally to a remote server 4 (
It must be understood that although they are shown outside the smart card 2a for the sake of convenience, the blocks SC and ILs comprise different internal modules of the smart card, which have been described in conjunction with
Conversely, the program OL is not necessarily stored in the terminal 1.
A first example of loading an applet in a smart card 2a will now be described, employing the method known as “GET”.
Let it be assumed that the file 7 for loading the applet has the structure shown in
The main steps in the process are schematically illustrated by
During a first step, the portion OL of the loading program, by a command of the “GET” type, retrieves a loading form from the smart card 2a; the form in HTML will arbitrarily be called “download.html”.
This retrieval is done by consulting a corresponding page whose URL typically takes the following form:
http://127.0.0.1:8080/download.html (3),
in which http://127.0.0.1:8080 is the URL feedback address per se, as defined by relation (1), and “download.html” is the HTML page to be obtained. This request employs a session between intelligent agents as has been described in conjunction with
The smart card 2a sends the form “download.html” in a second step, still by opening sessions between matched intelligent agents, by the method of the invention. The form obtained can be posted on a screen 5 by way of the navigator 10.
To define the concepts, one example of such a form 8 is illustrated in
The HTML code necessary for programming such a form is well known per se and is within the competence of one of average skill in the art. There is no need to describe it in detail again here. However, it might be noted that in particular it contains a line of code in HTML that is typically in the following form:
<form action=“http://127.0.01:8080/cgi-smart/loader”> (4),
in which http://127.0.01:8080 is the feedback URL from relation (1), cgi-smart is the aforementioned CGI directory containing the “loader” loading script that has been called “il”, that is, the script associated with the portion IL of the loading program.
If visual display of the form 8 on the screen 5 is not desired (for instance, if there is no human operator), the information can be cached incorporating the following HTML parameter: “TYPE=hidden” in the aforementioned line of code (4).
In a third step, the portion OL sends an http request of the “GET” type to the smart card 2a, still by opening sessions between matched intelligent agents. By calling up the CGI function offered by the smart card 2a, as has been described in conjunction with
The aforementioned request contains a line of code, typically in the following form:
Smart/loader?AID=xxx*ByteCode=yyy*Signature=zzz (5),
in which: “xxx” is the header 70 (“2001”, in the example of
The loading of a particular applet identified by the header 70 takes place at this moment.
Finally, in a fourth step, a return code is transmitted from the portion IL to the portion OL, still employing sessions between matched agents. In general, this involves a simple acknowledgment, or if the operation has not been performed correctly, an error code. In the latter case, steps 1-4 must be repeated.
As an alternative solution, it is possible to use the aforementioned “POST” method. To define the concepts,
Like the “GET” method, the “POST” method is well known per se and there is no need to describe it again here. In the specific context of the invention, the applet corresponding to the file “APPLET.BIN” is loaded from the unit “C” in a manner similar to what has been described for the “GET” method.
A second example of loading an applet in the smart card 2a will now be described.
It is equally possible to chain together a plurality of forms upon loading. Instead of a simple status (acknowledgment or error code in the first example described in conjunction with
For example, after analysis of the loading file, the portion IL can ask for an additional authorization (that is, an electronic signature), for instance in a governmental situation. It then sends the OL a form, which can typically have the following HTML structure (6):
in which authorization form, between the HTML flags called “<TITLE>” and <TITLE>, represent the (arbitrary) title of the form; “@card” is the literal translation of the URL wrap-around address of relation (1), and 8080 is the port number; the code line:
<INPUT TYPE=“text”NAME=“GovSignature”MAXLENGTH=“8”>Signature (7)
asks for the input of a variable, arbitrarily called “Signature”, in text mode, with a maximum length of 8 bytes; </FORM> is the HTML flag that indicates the end of the form code.
The complete process then includes two additional steps, with the final step of acknowledgement or an error code, making a total of six steps, as illustrated in
More generally, the number of round trips can depend on parameters involved in one or the other of the forms exchanged between the smart card and the portion OL of the loading programs.
Up to this point, the location of the portion OL has not been expressly specified. Aside from the face that the method a priori makes OL and IL compatible, it also makes a very great flexibility possible, precisely with regard to this location, it being expected that the portion IL is stored in the smart card 2a, forming one of the applications in this smart card. The method of the invention has the additional advantage in particular of no longer requiring physical proximity between the two portions OL and IL, since they are no longer tributaries of the ISO 7816 communication protocol, since the exchanges between these two software portions use the internet communication protocol TCP/IP.
Also, the portion OL, like the data per se of the applet to be loaded on the smart card 2a, can be stored either locally or at a remote site. In all these cases, however, the exchanges between these two portions, as has just been recalled, a communication protocol TCP/IP, and the loading of an applet is done as has been recalled above, thanks to the webserver/client and CGI functions offered by the smart card 2a.
The main architectures that can be employed in the context of the invention will now be described, in conjunction with
In the system architecture shown in
In the system architecture shown in
The system architecture shown in
In the architecture of
Also advantageously, the data Da of the applet to be loaded in the smart card 2a can be stored on an external data recording medium 9, such as a diskette, as shown in
If the aforementioned “post” method is used, it suffices to specify the letter of the storage unit, such as “A” for the diskette 9, a possible path (directory, subdirectories), and the name of the file to be loaded. To define these concepts, the complete path could typically be as follows:
A:/applet.bin (8)
In one of the characteristics of the method of the invention, because of the webserver/client function offered by the smart card 2a, the navigator 10 is at the same time capable, unlike in the prior art, of communicating directly with the latter, as has been demonstrated in conjunction with
The system architecture shown in
The system architecture in
It is clear that other architecture variants can be employed without departing from the scope of the invention. In particular, it is possible to load the data Da in the terminal 1 from various sources; for instance, from some other information processing system, connected to the terminal 1 by a local network, or by any other telematic means.
From reading the above description, it can easily be confirmed that the invention indeed attains the objects set for it.
Employing the loading of an applet in a smart card by the CGI interface of a webserver housed in this smart card has the following advantages, in particular:
Using forms in HTML standardizes the loading and makes the loading program portions OL and IL a priori compatible. In fact, as has been demonstrated, it is the portion IL located in the smart card that, in the fields of the form or forms sent, describes the loading parameterization that it is waiting for.
Furthermore, this mechanism of communication between the loading program portions OL and IL makes it possible in a simple way to manage the sequences of dynamic exchanges at the time of the loading.
Using the internet protocols HTTP and TCP/IP for the exchanges between the loading program portions OL and IL makes it possible to separate them physically. All that is necessary in the terminal is routing of packets IP. The loading can then be done in a nonspecialized smart card reader, since the ISO 7816 communication protocol is preserved. The terminal can be a simple standard microcomputer connected to the internet.
In an another advantageous aspect of the method of the invention, the applications stored in the smart card remain standard and accordingly have not been described again here. The smart card and the terminal themselves require only slight modification to be capable of accommodating the method of the invention: These modifications comprise implanting in these two units a communication protocol software layer, which has been called a specific layer and is a software layer that includes intelligent agents.
Alternatively, the loading program portion OL can be loaded dynamically in the terminal, through the card, either from it or from a remote http server.
A simple internet navigator can be used as the loading program OL.
However, it must be clearly understood that the invention is not limited only to the exemplary embodiments described explicitly, especially in conjunction with
Furthermore, instead of the HTML language, other similar languages, adapted to internet-type communication protocols, can be used, in particular the language known as XML.
The invention also relates to a method for loading a piece of software into a smart card from a terminal connected to said smart card by way of a smart card reader enabling communications by a first predetermined protocol, the terminal and the smart card including information processing means and information storage means, said loading being effected by the implementation and cooperation of first and second loading programs, said second loading program being stored in the information storage means of said smart card, characterized in that it includes at least the following phases:
a) a first preliminary phase, consisting of implanting, in the information storage means of said smart card (2a), a first piece of software (23a), forming a specific communication protocol layer;
b) a second preliminary phase, consisting of implanting, in the information storage means of said terminal (1), a second piece of software (13), forming a specific communication protocol layer;
1) opening a first data exchange session between at least said terminal (1) and said smart card (2a) thanks to said information processing means of the terminal and of the smart card, for the transmission of a request so that said first loading program (OL) will retrieve loading parametrizing data furnished by said second loading program (IL);
2) opening a second data exchange session between said smart card (2a) and at least said terminal (1) thanks to said information processing means of the terminal and of the smart card, to transmit said loading parametrizing data to said first loading program (OL), said parametrizing data including a reference to said instructions that are associated with said second loading program (IL); and
3) opening a second data exchange session between said smart card (2a) and at least said terminal (1) thanks to said information processing means of the terminal and of the smart card, and for submitting a loading file (7) taking said loading parametrizing data into account, said file including data (70, 71, 72) associated with said piece of software to be loaded (Da); interpretation of said set of instructions associated with said second loading program (IL), by implementation of said CGI function, in such a way as to generate a set of orders transmitted to said second loading program (IL) to execute this program (IL) and obtain said unloading of said piece of software (Da).
| Number | Date | Country | Kind |
|---|---|---|---|
| 0001661 | Feb 2000 | FR | national |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09958726 | Oct 2001 | US |
| Child | 12000766 | US |
