HK1036673B - Method for indivisibly modifying a plurality of sites in a microcircuit card non volatile memory, in particular a contactless card - Google Patents
Method for indivisibly modifying a plurality of sites in a microcircuit card non volatile memory, in particular a contactless card Download PDFInfo
- Publication number
- HK1036673B HK1036673B HK01107342.9A HK01107342A HK1036673B HK 1036673 B HK1036673 B HK 1036673B HK 01107342 A HK01107342 A HK 01107342A HK 1036673 B HK1036673 B HK 1036673B
- Authority
- HK
- Hong Kong
- Prior art keywords
- card
- terminal
- instruction
- memory
- session
- Prior art date
Links
Description
Technical Field
The present invention relates to microcircuit cards and, more particularly, to microprocessor cards that implement various modifications to their own non-volatile memory.
Background
When performing a transaction, the memory is typically modified one or more times, although all modifications must be determined to be correct before the newly recorded information is utilized, and when there is an error or recording corruption, the newly recorded information must be ignored or eliminated.
US-A-4877945 describes how anomalies are detected during writing of multiple datA items in case A transaction persists on the basis of an error condition.
In exceptional cases it is also desirable to be resilient, in other words the subsequent transaction is made with information values that have been recorded before the incorrect transaction was performed on the card.
The aforementioned US-A-4877945 does not provide this advantage because in some cases old information values are lost when an incorrect transaction is performed, so that the information cannot be reverted to an earlier state, at least not based solely on the information contained on the card.
WO-A-89/02140 describes A way of working but only applies to the case where A single item of information has been modified or where multiple items have been modified in A manner independent of each other.
However, in many cases, multiple data items need to be modified during a single transaction, and these multiple data items must be processed as "interactively related to each other" to ensure that all of the multiple data items are properly modified.
The use of a "contactless" card in this case entails a particularly high risk of imperfect or incomplete transactions of the plurality of associated data items, when the spatial boundaries at which the card can operate correctly around the terminal are not perceptible. In this case, the risk of an accidental interruption of the communication between the terminals by the card cannot be ignored, possibly because the card has moved beyond the range of the terminal before the end of the processing, or because of temporary disturbances, such as a piece of metal passing by.
An example, though not limiting, is where the card is used for remote ticket-checking transactions, such as at the entrance of a mass transit network, where the card plays two roles: a travel ticket; and an e-wallet role.
Several solutions have been proposed to alleviate the aforementioned difficulties and to make multiple writes or other modifications to "partitionable" data items that are related to each other.
The system known from the special use illustrated in the foregoing begins with the deduction of an electronic purse and then the recording of the right to the user to take a trip. If the user draws the card between two operations, the user is asked to present the card again and to resume writing the travel rights. However, if the user walks away without re-presenting the card, the user may be at fault. It is obvious that this cannot be done in the reverse order, and it is not possible for the user to try to extract the card later before the purse is closed.
This solution implies that the terminal is specifically configured to provoke an exception process to restart the transaction (requiring the card to be reinserted into the terminal) in case of interruption of the transaction. In addition to the software complexity of the terminal, such a solution is not entirely satisfactory if the user still makes an error without restarting the transaction.
Another solution consists in data interleaving, the terminal retaining the electronic wallet status information about the card and vice versa. This solution is satisfactory because, in addition to being complex, it also increases the capacity of the card to exchange data with the terminal, thus slowing down the execution of the transaction. It is difficult to apply when there are many (three or more) writes that cannot be divided.
Disclosure of Invention
It is an object of the invention to propose a method enabling multiple modifications of a card memory in a partitionable manner.
Another object of the invention is to propose a method that can be carried out entirely by the card. The method can be performed without modifying the terminal and without providing additional processing to the terminal, using the syntax of the original instructions, and thus is extremely resilient in the available instructions.
In order to achieve the above object, the invention provides a method for modifying the content of a non-volatile memory in a microcircuit card, in which method the card is temporarily coupled to a terminal when performing a transaction, said transaction comprising the application by the terminal of a plurality of commands to the card, each command comprising at least one operation of recording in the card memory a respective data item specified by the command, the data items recorded in this way being interrelated, and the data items recorded in this way being
a) When receiving corresponding instructions from the terminal, the card temporarily records each of the correlated information items in a card memory; then the
b) The recording operation is ended so that in the subsequent operation the instructions executed in step a) will all be taken into account or all be invalidated.
The method is characterized in that the instruction is a modification instruction; in step a), the step of recording the new values of said items in the memory modifies the content of the memory without losing the previous values of said items; and in step b), ending the recording operation such that if all instructions executed in step a) fail, the data in the non-volatile memory will retain its state prior to step a).
In the method of the invention, in the case of confirmation made in step b), a flag confirming proper execution is recorded in the card memory; and when the card subsequently receives an instruction to read and/or modify at least one data item written in step a) or the value corresponding thereto, the card starts checking the state of said mark, if said mark has not been recorded, the card ignores or cancels the temporary recording previously made in step a), and executes said instruction based on the previous value corresponding to said data item. When the card checks the state of the mark, if the mark has been recorded, the card performs a copy operation on the content temporarily recorded in step a).
In the method of the invention, the card is adapted to operate in two modes, namely: a conversation-in-progress mode in which recording is performed by performing steps a) and b); and ending the session mode in which none of the recordings made by steps a) and b) are confirmed.
In the method of the invention, an authentication function may be included, said authentication function being combined with the function of ending step b), forcing step b) to be discarded in case of authentication failure. The authentication is performed by the card, which authenticates the authenticity of the terminal and/or the authenticity of the data exchanged between the terminal and the card, the card verifies an encrypted approval generated by the terminal and transmitted to the card, and the modification in step b) is confirmed only if the encrypted approval is recognized as correct.
In the method of the invention, when the card receives an instruction from the terminal, said instruction requiring to modify the content of the memory and comprising proving an encrypted approval, if the instruction is received after the end of the session, said proving operation is performed; if the instruction is received while the session is in progress, the attestation operation is not performed.
In the method of the invention, the authentication is performed by the terminal which authenticates the authenticity of the card and/or the authenticity of the data exchanged between the terminal and the card, the card conditionally generates an encrypted approval if and only if the modification is confirmed in step b), and transmits said encrypted approval to the terminal.
In the method of the invention, when the card receives an instruction from the terminal, said instruction requiring to modify the content of the memory and including generating an encrypted approval, if the instruction is received after the end of the session, said generating operation is executed; if the command is received while the dialog is in progress, the generating operation is not executed.
In the method of the invention, when the card receives in step b) an instruction from the terminal, said instruction requiring a modification of the memory and of the content and comprising the generation of a plurality of encrypted approvals, these encrypted approvals are stored in step b) if and only if said modification is confirmed in step b), and then transmitted together to the terminal.
In the method of the invention, at least part of the instructions executable in step b) comprise a selective suppression attribute, and if the card executes such an instruction in the course of a dialog in step b), the modification performed by said instruction is independent of the result of step b).
In the method of the invention, it is further provided that after step b) and after the modification has been confirmed, the following sequence of steps is performed: d) the terminal machine executes the action after the card confirmation; and e) recording the evidence information on the card for subsequent reading access, if the terminal performs said action properly.
In the method of the invention, the recording command of step e) is an implicit command, and any command received by the card after step b) is interpreted as a command to record the authenticity data on the card.
Detailed Description
The inventive method belongs to the field of a card temporarily coupled to a terminal while performing a transaction, which comprises the application by the terminal of a plurality of modification commands to the card, each modification command comprising at least one operation for recording on a card memory an individual data item specified by the command, the individual data items recorded in this way being mutually associated with one another. In a characteristic manner of the invention, the method comprises the following steps performed by the card: a) when receiving individual command from the terminal, temporarily modifying the card memory without losing the corresponding previous value of each item by temporarily recording each item of information having an interactive relationship in the card memory; and then b) ending the modification via a total confirmation or a total discard, so that in subsequent jobs the instruction executed in step a) has been taken into account, otherwise all is not affected.
Thus, the inventive concept involves bringing together multiple modifications to be made in a single step a) in an inseparable manner, and then confirming these modifications in their entirety in the card after they have been performed. If the validation is successful, then the operation performed next by the card (whether during the same transaction or during a subsequent transaction), the contents of the access necessarily reflect the modification that has been made.
Conversely, any interruption of the card operation during step a) will cancel the modification performed in its entirety, the data in the non-volatile memory remaining in the state before step a).
In a special implementation, in the case of the confirmation of step b), a mark is recorded on the card memory confirming that it has performed properly; when the card subsequently receives a command requesting that at least one data item written in step a) or its corresponding value be read and/or modified, the card starts to check the status of the mark, if no mark has been recorded, the card ignores or cancels the previous temporary recording made in step a), and executes the commands based on the previous value corresponding to the data item. If the card is found to have been recorded while viewing the status of the mark, the card will copy the temporary write operation performed in step a).
The best card is suitable for dual mode operation, i.e. a dialogue in-progress mode, in which recording is done by performing steps a) and b); and ending the dialogue mode, wherein neither step a) nor step b) is confirmed for recording.
Opening a session may be represented, for example, by a card reset to zero or may be interpreted by a command having two actions, one of which performs a predetermined task while being interpreted as opening a session.
For example, when the certificate fails to complete the normal approval record, the card automatically opens a section of the ongoing processing record of the session.
In the same manner, ending a dialog may be preceded by an instruction that may perform two actions, for example: a predetermined job is executed and at the same time interpreted as an instruction to close a session.
For example, the electronic wallet debit transaction ends the session, thereby avoiding the need to communicate with the resulting approval, thus rendering the session approval and electronic wallet transaction approval inseparable.
More preferably the method comprises the step of combining the functions of step b) with the authentication function, forcing step b) to be discarded in case of authentication failure.
In a first embodiment, the authentication is carried out by the card verifying the authenticity of the terminal and/or the authenticity of the data exchanged between the terminal and the card, the card checking being effected by the terminal by generating an encrypted authorization and transmitting it to the card, the modification in step b) being verified only if the authorization is confirmed to be correct.
The temporary modification can be made during the session mode, so that when the card receives the command from the terminal to modify the memory contents and including confirming the password approval, it is proved whether the command is received to end the session, if the command is received in the session, it is not necessary to do so.
In other words, the instructions executed by the card in step b) and the instructions normally (i.e. to end the session) confirm the encrypted approval, and when executed during the session, such confirmation is no longer included, performing a corresponding function with "authenticity of the session approval terminal".
In a second embodiment, the authentication of the authenticity is carried out by the terminal, which authenticates the authenticity of the card and/or the authenticity of the data exchanged between the terminal and the card, and if the modification is confirmed in step b), the card is conditionally generated and transmits an encrypted authorization to the terminal.
In the session mode, a temporary modification may be made so that the card receives instructions from the terminal for modifying the memory contents including generating an encrypted authorization, and if the instructions are received after the session is completed, the operation is performed, and if the instructions are received while the session is in progress, the operation need not be performed.
In other words, when the command executed by the card in step b) and the command to generate the encrypted authorization are normally generated (i.e. to stop ending the session), the authorization is not generated when the command is executed during the session, and the corresponding function is executed by "performing authorization to verify the authenticity of the terminal".
Temporary modifications may be made so that when the card receives a command from the terminal in step b) requesting a modification of the memory contents and comprising the generation of a plurality of encrypted approvals, these are stored in step b) and are finally transmitted together to the terminal if the modification has been verified in step b).
In other words, an encrypted approval resulting from the card exhibition communication, typically resulting from the command of step b), is specified. Particularly if the write command that is approved generates some write approval, it is desirable to leave the card only after the write has been executed unalterably.
In a particular implementation, at least part of the instructions possibly executed in step b) comprise selective suppression attributes, and if the card executes such instructions in the course of a dialog in step b), the modification performed by the instructions is performed independently of the result of step b).
In other words, the attribute definition instruction is executed while the dialog is in progress (i.e., will be cancelled if the dialog is not completed), or when the dialog is ended (i.e., is immediately valid as if the dialog has been completed, even though it is still in progress in time).
Preferably the invention further provides after step b) and in the event of a confirmed modification, the following sequence of steps: d) the terminal machine executes certain action according to the confirmation of the card; and e) if the action is properly performed by the terminal, the verification information is recorded on the card for convenient subsequent access by reading.
Such "empirical" conversation notification cards do allow the terminal to take decisions after the conversation is performed (e.g., for public transportation network import and export gate opening).
It is observed that such an evidence is handled by the card without additional writing (a copy of the temporary writing is a task that needs to be executed sooner or later). In addition, the only situation where such a card is executed at the copy end is when the actions have been properly executed at the terminal end, i.e. the entire transaction is consistent.
In the case where all operations are performed by the card, it is preferred to provide that the recorded instruction of step e) is an implicit instruction and that any instruction received by the card after step b) is interpreted as a command to record the authenticity information on the card.
Other features and advantages will be apparent from the following description of two embodiments of the invention.
In these instances, and indeed throughout the text, the term "specifying" is used to mean "one of a particular plurality" and is an action that characterizes a particular item of information among a plurality of items contained in the card.
Such designation may be internal, as the command itself specifies a particular piece of information, such as the command "X amount debited from the wallet" indicates that the memory bit is containing the "wallet last" data item value.
The designation may also be explicit, as shown in example I below, which specifies that the write command has an address or sector identification number, the command being indexed by index I.
Example I
A card is provided that can store 100 8-byte credits and can execute the following commands:
*reading the 8-tuple value v specified by the index i in the range of 1 to 100;
*writing an 8-bit group value v specified by an index i in the range of 1 to 100;
*opening a session;
*a session is ended.
The card allows up to three writes in one session. It is customary to use upper case letters to indicate the value of a non-volatile memory (e.g., EEPROM) and lower case letters to indicate the value of a volatile memory (RAM, the contents of which disappear when not powered).
The non-volatile memory segment allocates a primary data storage area of the working memory (deterministic write);
*V[i]for i ranging from 1 to 100: 100 x 8 bytes.
Another non-volatile memory segment is allocated to the dialogue mechanism and includes:
*T[k]j for 1 to 3: 3 x 8 bytes
A value containing a dialog process write (temporary write);
*I[K]j for the range 1 to 3: 3 x 1 bytes
An indicator containing a written value of the dialog process; and
*c: the count byte is written at the end of the session.
C encoding the write-in times executed in the conversation process; an appropriate redundancy mechanism (e.g., incorporating the complement of the value) may detect the case where the value of the count byte is indeterminate.
The operation is performed as follows.
Step 0: checking C at the instant between the card being powered and the execution of the first command. If it is a defined value in the range from 1 to 3, then for k equal to 1 to C, at the index I [ k ]]Value of (a) T [ k]From table V [ i ]]And (6) copying. Then C is reset to zero and the internal variable j is set to-1 (indicating that a dialog has not been opened).
Step 1: in reading, a test is performed to see if j is greater than 0: if so, the requested index I is applied to k in decreasing top order from j to 1 and I [ k ]]And (6) comparing. If there is match, return T [ k ]]. All other cases are sent back to V [ i ]]。
Step 2: when a dialog is opened, j is initialized to 0 (if the dialog is open)Cancelled if already turned on).
Step 3: if j is-1 (dialog not on) at each write, the communication value V is at T [0]Write, communication indicates that I is at I [0 ]]Writing, writing C ═ 0 followed by V at V [ i]Write and write C ═ 0: if O is less than j < 3 (written during the session), j is increased by 1, v is added to T [ j ≦ j]Write, and I in Ij]Writing; if j is 3, the operation is rejected (the upper limit of write in progress for one session has been exceeded).
Step 4: in the course of ending the session, if j > 0, j is written in C, and then j is 1 to C, copied in Table V2]In the reference ij]Value of (a) T [ j]. Then C is set to 0 and j is set to-1.
It is clear that the power supply to the card may be interrupted at any instant and that the reading of the value is correct, i.e. for each index i the last written value is not in progress in the session or the writing of the session has ended (when a non-zero value is written in C, the writing has been completed or the session has ended).
Encryption is added to prevent certain operations from occurring when the encrypted approval supplied to the card is incorrect and/or to generate encrypted approval for the card at the end of a certain operation.
The cryptographic approval used is based on the known cipher type. For example, "the session approval verifies the authenticity of the card" (or the terminal) is obtained by applying a Secure Hash Algorithm (SHA) to the data supplied to the card (or the terminal) at the card end and at the terminal end when the session is opened and/or to the random numbers supplied to the terminal (or the card); the information confirmation code (MAC) obtained from the above is verified by the card (or terminal) using the Digital Signature Algorithm (DSA) of the key book contained in the card (or terminal); the terminal (or card) validates the signature using the public key. Symmetric encryption algorithms such as data encryption standards may also be used to generate Message Authentication Codes (MACs) and/or generate signatures.
The step of generating the message confirmation code is common to the mutual authentication and is carried by the data of all the conversations. When symmetric encryption is used, authentication by the authentication card and authentication by the authentication terminal can be obtained in a single step of coding the secret code by the message authentication code, the card and terminal being authenticated by a unit operation such as capturing a predetermined token.
Example II
In this example, the data of the memory is organized as sectors, each sector containing four fields:
1. data;
2. an identifier (which may select an access key for a sector);
3. suitability: if two segments have the same identifier, then it is decided which sector is suitable; and
4. and (4) checking: the first three fields are corrupt (e.g., performing a parity check).
A sector is identified by its identifier, which informs the replacement location notification. The sector write process has an identifier as a parameter along with data associated with the identifier. The read sector program has an identifier as a parameter that returns data associated with the identifier when the last time the identifier was used (or an appropriate indication if the identifier was not used) to perform the write. In other words, associative accesses are performed instead of index accesses.
During reading of a sector, the card searches for sectors that carry the identifier containing the desired value and are not corrupted (determined by the check field). When multiple sectors can meet both criteria, a particular sector is retained based on the suitability field.
When writing to a sector, the card writes the following to the appropriate sector: the required data; a recognizer; the appropriate field is such that during the read process, the sector is the most suitable non-corrupt sector with such an identification; and a check field that matches the first three fields (i.e., the write is handled in such a way that it can be read later as appropriate).
The preferred write process is followed by removing sectors that have become unsuitable by writing new sectors so that a new sector can be utilized.
It is also preferable to provide a system that is (extra) resource-reclaiming, i.e. reclaiming by a system sectors that may have been useless due to corruption or due to misappropriation.
It is preferable to provide a system that delays wear due to writing, ensuring that the same sector is not used often, such as by randomly employing a sector from among the available multiple sectors.
A generally elegant variant of the search for a sector procedure involves using a search step to eliminate sectors that have found corruption and the x or not best suited sectors thereby regenerating free sectors (the time consuming read-specific process is advantageous for subsequent read and write rates). It is preferable to rewrite the eligible sectors before eliminating a sector that has been found to be uncorrupted but not eligible because it may be a result of an improper write.
The memory workload is equal to the number of available sectors minus one sector that must remain erased. All sectors (including the eliminated sectors) are dynamically distributed within the memory.
If the data is to be structured in a file, for example using the ISO/IEC 7816-4 standard, the sector identifier is divided into two fields: file identifier and sector identifier inside the file.
Non-limiting implementations of write/read operations using this particular sector structure are as follows:
the following description of performing read and write operations using this particular sector structure (without limitation):
*the check column contains the zero bit number of other three columns by binary code; it is clear that if there is a problem, such as interrupting writing or eliminating the number of bits in all the same direction in the modified sector, checking the value of the check field can often detect that a problem has occurred.
*The appropriate field is an integer from 0 to 3 encoded in two bits.
*ReadingThe program sequentially tries to take all sectors until the first sector is found to have the identifier sought and is uncorrupted. If no sectors are found, the procedure ends and reports "sectors not found". If the first sector is found, its location is stored along with its data and its suitability P. And continuously searching. If the second sector is found to have the sought identifier and is not corrupt, testing if its suitability q is the remainder of p +1 divided by 3 full divisions; if so, rewriting the second sector, eliminating the first sector, and returning the data from the second sector; otherwise, the first sector is overwritten, the first sector is erased, and data from the first sector is returned. If a second sector is not found and if the suitability of the first sector is p-3, this sector is eliminated and a "not found sector" is reported; otherwise the data returned is from the first sector found.
*The write process starts similar to the read process described above. If a previously stored sector is found that has been returned by the read procedure by a particular identifier, this sector location is retained along with its suitability p (equal to 0, 1 or 2); if no such sector is found, a free sector is selected (selected using the procedure described below) and the identifier, data, suitability p 3 and check field are written to the sector, preserving the location and suitability of the sector. Both cases proceed by selecting a free sector (using the procedure described below). The identifier, data, fitness P (calculated as the remainder of a division of P +1 by 3), and the check field are written to this sector. And then eliminate any previously stored sectors if any.
To find a free sector, the number of found free sectors n is initialized to zero. The sectors are sequentially verified. For non-blank and corrupt sectors, then eliminating it from being blank (thus facilitating the aforementioned resource reclamation); remove the sector if it is not corrupt and if the suitability is p-3 (also to resource recovery); if the sector is uncorrupted and if its suitability is not p-3, then the unscanned segment is searched for another uncorrupted sector with the same identification: if one is found, the non-suitable subzone is eliminated, as is the read procedure: if the sector is blank at the end of the process, finding the number n of the free sectors to be increased progressively, and taking out the random integer from 0 to n-1; if the integer is 0, then the empty sector location is stored. When all sectors have been scanned, all non-blank sectors are uncorrupted, no two sectors have the same identity, the number of blank sectors n is known, and one of them has been stored as a random choice in an equal probability manner. If no free sectors are found, the write process is interrupted.
The way in which the card handles such a particular sector structure with inseparable modification sessions is described later.
To store the non-divisible modifications, the card has n sectors available in non-volatile memory that have been eliminated (where n corresponds to the number of non-divisible modifications that may be required to be made in a single session). In addition, the card processes a section of non-volatile memory dedicated to processing a session (not included in a sector), referred to as a "session descriptor".
This implementation has no specific authentication of the session.
The dialog descriptor is defined by three fields:
*a reference list of non-partitionable sectors (LRSA);
*forming a verification Value (VCC) of a reference form of the non-divisible sector; and
*consider a check Value (VCPC) that cannot partition a sector reference form for finding whether a session is over.
Step 0: initialization: the card must determine that the session descriptor has been removed since the last interruption of the card operation, such as resetting, before the initial access to the data is initiated. Some cases need to be taken into account depending on the state of the dialog descriptor.
*And (3) completely eliminating: the card remains unchanged;
*not completely eliminated, and VCPC is correct: card search and erase (if needed)) All sectors that have been written to change useless (from the reference form), then eliminate the dialog descriptor;
*not completely eliminated, VCPC is eliminated or incorrect, and VCC is completely correct: the card eliminates the sector given by the LRSA and then eliminates the dialog descriptor; or
*Not completely eliminated, VCPC is eliminated or incorrect, and VCC is eliminated or incorrect: the card eliminates the dialog descriptor.
Step 1: opening a conversation: the card looks for n sectors to be eliminated and then records the reference form at the VCC of the dialog descriptor (which is assumed to be eliminated).
Step 2: in the process of conversation: the card accepts the instruction. When one of the instructions generates one or more non-partitionable modifications, the sectors used to record these modifications are recorded at the LRSA up to all n modified sectors.
And step 3: ending a conversation: to end the session, the card writes to the VCPC, which ensures that the LRSA and its VCC have been taken into account. All sectors (from the reference list) that have been written to and are changed to be useless are then searched for and eliminated. The dialog descriptor is then eliminated.
In addition, if it is a card to process the demonstration, the dialogue process includes the following modifications:
step 0: initialization: in the case where the session descriptor is not completely eliminated and the VCPC is correct, the card looks for and eliminates (if necessary) the sub-fields (from the reference form) that have all been written to and rendered useless, but does not eliminate the session description.
Step 1: opening a conversation: the card is opened in a volatile memory recording session. If the dialog descriptor is not blank, the card indicates that the previous dialog has not been validated, even which data item has not been validated by analyzing the LRSA. The dialog describer is not modified in any way.
Step 2: in the process of conversation: if there is a desired card to eliminate the dialog descriptor, the n eliminated sectors are searched and written into the LRSA and its VCC.
And step 3: ending a conversation: the card records the session without opening in the volatile memory. The dialog descriptor is not eliminated anyway.
Claims (13)
1. A method for modifying the content of a non-volatile memory in a microcircuit card, in which method the card is temporarily coupled to a terminal when performing a transaction, said transaction comprising the application by the terminal to the card of a plurality of commands, each command comprising at least one operation of recording in the card memory a respective data item specified by the command, the data items recorded in this way being interrelated, characterized in that said method comprises the steps of:
a) when receiving corresponding instructions from the terminal, the card temporarily records each of the correlated information items in a card memory; then the
b) The recording operation is ended so that in a subsequent operation, the instructions executed in step a) will all be taken into account, or all be invalidated,
wherein the instruction is a modify instruction;
in step a), the step of recording the new values of said items in the memory modifies the content of the memory without losing the previous values of said items; and is
In step b), the recording operation is ended such that if all instructions executed in step a) fail, the data in the non-volatile memory will retain its state prior to step a).
2. The method of claim 1, wherein:
in the case of confirmation made in step b), recording in the card memory a flag confirming proper execution; and
when the card subsequently receives an instruction to read and/or modify at least one data item written in step a) or the value corresponding thereto, the card starts checking the state of the mark, if the mark has not been recorded, the card ignores or cancels the temporary recording previously made in step a), and executes the instruction based on the previous value corresponding to the data item.
3. The method of claim 2, wherein when the card checks the state of the mark, if the mark has been recorded, the card performs a copy operation on the contents temporarily recorded in step a).
4. The method of claim 1, wherein the card is adapted to operate in two modes:
a conversation-in-progress mode in which recording is performed by performing steps a) and b); and
ending the session mode in which the recordings made in steps a) and b) are not confirmed.
5. The method according to claim 1, characterized in that it comprises an authentication function, combined with the function of ending step b), forcing step b) to be discarded in case of authentication failure.
6. Method according to claim 5, characterized in that the authentication is performed by a card which authenticates the authenticity of the terminal and/or the authenticity of the data exchanged between the terminal and the card, the card checking an encrypted approval generated by the terminal and transmitted to the card, and the modification in step b) is confirmed only if the encrypted approval is recognized as correct.
7. The method according to claim 4 or 6, characterized in that when the card receives an instruction from the terminal, said instruction requiring the modification of the contents of the memory and comprising the certification of an encrypted approval, said certification operation is performed if the instruction is received after the end of the session; if the instruction is received while the session is in progress, the attestation operation is not performed.
8. The method of claim 5, wherein the authentication is performed by the terminal which authenticates the authenticity of the card and/or the authenticity of the data exchanged between the terminal and the card, and if and only if step b) confirms the modification, the card conditionally generates an encrypted approval and transmits the encrypted approval to the terminal.
9. The method according to claim 4 or 8, characterized in that when the card receives an instruction from the terminal, said instruction requiring the modification of the contents of the memory and comprising the generation of an encrypted confirmation, said generation is performed if the instruction is received after the end of the session; if the command is received while the dialog is in progress, the generating operation is not executed.
10. The method of claim 1, wherein when the card receives instructions from the terminal in step b) that require modification of the memory and contents and that include the generation of a plurality of encrypted approvals, the encrypted approvals are stored in step b) and then transmitted together to the terminal if and only if the modification is confirmed in step b).
11. The method of claim 4, wherein at least some of the instructions executable in step b) include a selective suppression attribute, and wherein the modification performed by the instructions is independent of the results of step b) if the card executes such instructions in step b) while the session is in progress.
12. The method of claim 1, further providing that after step b) and after the modification has been confirmed, the following sequence of steps is performed:
d) the terminal machine executes the action after the card confirmation; and
e) with the terminal properly performing the action, the authentication information is recorded on the card for subsequent read access.
13. The method of claim 12 wherein the recorded instructions of step e) are implicit instructions and any instructions received by the card after step b) are interpreted as commands to record the authentication data on the card.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR98/04453 | 1998-04-09 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| HK1036673A HK1036673A (en) | 2002-01-11 |
| HK1036673B true HK1036673B (en) | 2005-07-29 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11523153B2 (en) | System and techniques for digital data lineage verification | |
| CN1201248C (en) | Shared name | |
| EP1469369B1 (en) | Verbose hardware identification for binding a software package to a computer system having tolerance for hardware changes | |
| EP1455258B1 (en) | Compact hardware identification for binding a software package to a computer system having tolerance for hardware changes | |
| CN1079968C (en) | Data exchange system comprising portable data processing units | |
| CN112100624B (en) | Firmware protection method and device and terminal equipment | |
| US20060174077A1 (en) | Software memory access control | |
| MX2007011377A (en) | Secure boot. | |
| US11232194B2 (en) | Method for executing a binary code of a secure function with a microprocessor | |
| CN1535405A (en) | Controlling access to electronically stored and protected data contents | |
| CN1527208A (en) | Method and device for realizing computer safety and enciphering based on identity confirmation | |
| RU2348968C2 (en) | System for interlinking of secrets with computer system having some tolerance on hardware changes | |
| CN107958141A (en) | A kind of method for protecting software based on chip ID number | |
| CN1252626C (en) | Content sender machine, content receiver machine, authorizing method and system | |
| KR101698211B1 (en) | Method for authenticating a storage device, machine-readable storage medium and host device | |
| JP4838381B2 (en) | A method for inseparably correcting a plurality of non-volatile memory locations in a microcircuit card, particularly a contactless card | |
| CN1523483A (en) | storage device | |
| CN114329357A (en) | Method and device for protecting code security | |
| HK1036673B (en) | Method for indivisibly modifying a plurality of sites in a microcircuit card non volatile memory, in particular a contactless card | |
| HK1036673A (en) | Method for indivisibly modifying a plurality of sites in a microcircuit card non volatile memory, in particular a contactless card | |
| US8484484B2 (en) | Method of sending an executable code to a reception device and method of executing this code | |
| JP3491273B2 (en) | Chip card and how to import information on it | |
| US7392523B1 (en) | Systems and methods for distributing objects | |
| WO2021015204A1 (en) | Access control device, access control method, and program | |
| CN111984940B (en) | SO file reinforcement method, device, electronic device and storage medium |