EP1031260A2 - Methods and apparatus for the secure identification and validation of things and events - Google Patents
Methods and apparatus for the secure identification and validation of things and eventsInfo
- Publication number
- EP1031260A2 EP1031260A2 EP98951640A EP98951640A EP1031260A2 EP 1031260 A2 EP1031260 A2 EP 1031260A2 EP 98951640 A EP98951640 A EP 98951640A EP 98951640 A EP98951640 A EP 98951640A EP 1031260 A2 EP1031260 A2 EP 1031260A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- entity
- identification
- result
- presumed
- arbitrator
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
Definitions
- the present invention generally relates to methods for identification, including remote identification and validation of messages.
- the methods of the present invention provide security in various transactions by validating and identifying various entities, while avoiding the necessity of conventional authentication procedures or the need to store databases of information available to an identification device.
- Various service providers e.g., Social Securities, Telecoms (PATS), financial institutions, brokers, banks, merchants, etc.
- PATS Transactional Securities, Telecoms
- financial institutions e.g., financial institutions, brokers, banks, merchants, etc.
- remote entity e.g., an individual, organization, smart card, message, account, etc.
- These service providers often provide their services to remote entities over various telecommunications media, for example, Internet, phone lines, etc.
- identification devices to identify and validate remote entities, these devices being referred to herein as Identification Devices.
- Authorized Remote Entity a remote entity authorized to engage in transactions, but perhaps not yet identified and/or authenticated by an Identification Device for a particular transaction, is referred to herein as an "Authorized Remote Entity" or “Authorized Entity.”
- Identification Devices One method commonly known in the art and employed by Identification Devices for securely identifying a remote entity is to add "authentication" to an otherwise normal identification process. Authentication is typically accomplished by providing an additional piece of information to an Identification Device, e.g., a secret code, along with identification information. This additional information then may be used to corroborate that the identification is accurate and that the remote entity is not an imposter attempting to impersonate an authorized entity.
- the additional piece of information is often a secret code or a password (e.g., PIN), but also may be a Dynamic Code, preferably computed using a software implemented algorithm.
- the additional information may be provided by a token (e.g., Bio-Token) carried by the entity (e.g., individual) to be identified.
- Non-variable (i.e., constant or static) information or data can only add limited security to the identification process because a static piece of information eventually may become known to a third party (e.g., potential attacker/impostor/eavesdropper) in which case an authorized entity can easily be impersonated.
- authentication by means of a variable piece of information (referred to herein as a Dynamic or One Time Code) provides enhanced security.
- a Dynamic or One Time Code provides enhanced security.
- known methods of authentication which use a Dynamic or One Time Code typically require a prior step of identifying the remote entity to the Identification Device, e.g., by providing a name (e.g., a login name), a serial number, an additional fix code, etc.
- a method commonly employed by an Identification Device to securely identify a Remote Entity by authentication typically comprises the three following steps:
- Identification identify who the Remote Entity is supposed to be, by receiving a constant (non- variable, or at least non-constantly-variable) piece of information, referred to herein as an Identification Message; 2) Database Search: the Identification Devices searches a database containing the
- the Remote Entity is identified (as described in step 1 above);
- the Remote Entity receives a Challenge generated and sent by the Identification Device and computes a Response, the Response playing the role of a Dynamic Code; 3) The Identification Device, after identifying the Remote Entity (the Pre-
- Authentication Identification requires a database to determine the expected response to the challenge, for that Remote Entity at that moment.
- Each of the authentication schemes described above requires the Identification Device to employ a database or look-up table.
- each database must be maintained and updated, which creates problems associated with the management of keys, synchronized database updates, etc.
- these problems become acute when a service provider utilizing an authentication process has a multitude of Identification Devices disseminated through several countries. Accordingly, methods of authentication are needed which overcome limitations and drawbacks associated with the use of databases in authentication methods currently known in the art.
- Remote Entity Another problem associated with conventional schemes for Remote Identification is the possibility of "repudiation" by an identified and authenticated Remote Entity.
- a Remote Entity which has been identified and authenticated as being an Authorized Entity, may later deny the genuineness of a particular communication or event under scrutiny.
- Remote Entities e.g., gamblers
- the Gambling Service Provider identifies and authenticates that Remote Entity by a procedure similar to those described above.
- a further drawback of authentication methods known in the art and described above is the fact that a Remote Entity is trackable. In other words, an eavesdropper may follow every transaction made a particular Remote Entity because that Remote Entity transmits the same constant identification information for every transaction. This ability to track a Remote Entity creates a lack of security and privacy for many Remote Entities (e.g., especially government officers, ministers, police officers, etc.). Accordingly, new methods of identification are needed which avoid the trackability of Remote Entity transactions.
- the present invention discloses methods for secure identification of entities, whereby no authentication process is necessary.
- the present invention comprises various One Step/One Way Identification Procedures whereby only a secure identification step is required, without the need of an additional authentication step.
- these methods of identification help to avoid the possibility of impersonation because a part of each identification process is variable and valid only one time. Consequently, the identification process cannot be intercepted and re-used, is non-repudiable and is non-trackable.
- the need for an Identification Device, as described above, to have access to a database of authentication data is alleviated.
- the invention comprises the use of Reversible Algorithms, as shown below, in accordance with the principles disclosed in US patent 5,524,072 issued to Labaton et al., hereby incorporated by reference.
- reversible algorithms may be used in conjunction with a Challenge-Response method similar to that described above, wherein a Identification Device generates a random challenge. This challenge then may be transmitted to a Remote Entity.
- the Remote Entity generates a substantially or totally dynamic response (i.e., little or no constant part), and such response constitutes "secure identification information.” It is important to emphasize at this point that, according to a preferred embodiment of this invention, an Identification Device does not need to know the identity of any Presumed Entity in order to identify a particular Remote Entity.
- an Identification Device is capable of checking the identification of a Remote Entity without the need of a database and without the need to know in advance who the Remote Entity is supposed to be (i.e., without the need to know an Authorized Entity).
- This invention further provides methods for non-repudiable identification, which means that the Remote Entity will not be able to claim that a Service Provider fabricated the identification message. This is accomplished by providing three different entities, namely, a Remote Entity, a Service Provider/Identification Device and an Arbitrator, wherein no single entity has access to all of the necessary data.
- the present invention further provides for systems and methods wherein a Response computation is composed of more than one step, the first step being a computation of the result (Rl) inferred from the Arbitrator Seed number.
- the result Rl will be one of the arguments of the Reversible Algorithm.
- an anti-repudiation feature comprises the following steps: first, a Service Provider receives an identification message from a Remote Entity; second, the Service Provider applies the reverse of the Reversible Algorithm to the signature, and recuperates the original arguments, including Rl . Because Rl is computed by the remote entity using the Arbitrator seed number, which is not known to the Service Provider, that means that a correct Rl , validated and corroborated by the Arbitrator, can come only from the Remote Entity, and can not be fabricated by the service provider. BRIEF DESCRIPTION OF THE DRAWING FIGURES
- Figure 1 is a block flow diagram of an exemplary initialization process for an Arbitrator and a System (e.g., a Service Provider which operates an Identification Device, ID
- Figure 2 is a block flow diagram of an exemplary identification process for a challenge-response type identification according to the methods of the present invention
- Figure 3 is a block flow diagram of an exemplary anti-repudiation process
- Figure 4 is a block flow diagram of an exemplary identification process according to the methods of the present invention.
- Figure 5 is a block flow diagram of an exemplary time-based identification process, with drift correction, according to the methods of the present invention
- Figure 6 is a block flow diagram of a further exemplary time-based identification process, with drift correction, and wherein an Identification Device has access to a database
- Figure 7 is a graphical representation of a preferred FTolerance function.
- the present invention provides methods for secure identification of a Remote Entity by an Identification Device, wherein the Identification Device may not require the use of a dedicated local database. Furthermore, the methods of the present invention may provide for one-way, non-repudiable, non-trackable identification.
- an Identification Device is operated by a Service Provider, or any other entity requiring secure identification of Remote Entities, to engage in transactions with those entities (for simplicity, referred to herein as a Service Provider).
- a reversible algorithm (referred to herein as a Reversible Function) F_SYS ssn may be selected by a Service Provider out of a family of possible algorithms, preferably by selecting a System Seed Number (or SSN).
- the Service Provider then may distribute the reversible algorithm to any or all of the Remote Entities authorized to engage in transactions with the Service Provider (Authorized Remote Entities).
- the Service Provider also may provide a specific Remote Entity Identification number (referred to herein as C_ID) to each of the Authorized Remote Entities (e.g., a driver's license number).
- a Remote Entity may be identified by a Service Provider (e.g., for a particular transaction between the Service Provider and the Remote Entity)
- the Service Provider may select a random number (referred to herein as Ch or Challenge) and transmits it to the Remote Entity.
- the response (R2) then may be transmitted to the Service Provider's Identification Device.
- the reverse of the system function F_SYS ssn (referred to
- the Identification Device then may compare Ch (sent) to Ch' (received/computed) and determine whether they match. If they match, C_ID is a correct and valid identification.
- the present invention may utilize a Rabin Algorithm (known in the art).
- the Service Provider may select two large prime numbers, Pj and P2, each of them being congruent with 7(mod 8), or alternatively, select a System Seed Number (SSN), from which two such prime numbers may be consequently inferred (See Figure 1, blocks 5 and 6). These two prime numbers will determine, as parameters, the Reverse Algorithm, as explained below, but the prime numbers will not be transmitted or communicated to the Remote Entity, and will remain as secret system keys under the supervision of the Service Provider (See Figure 1, block 7).
- SSN System Seed Number
- the F_SYS ssn may be masked on a chip.
- a preferred exemplary model for the function F_SYS ssn may be specified as a function FFj
- the Remote Entity may make the following computations:
- n is the amount of digits of the concatenation Ch o C ID
- the Remote Entity then may concatenate cl,...,cn and refer to the concatenation as C as follows:
- the Remote Entity may bitwise-xor C with the concatenation Ch o C_ID as follows (where "xor” corresponds to the "exclusive or” function):
- the Remote Entity may compute Tn+m (m being any natural number) in the following manner:
- a Remote Entity may transmit the Cipher R2 to an Identification Device. Because the Identification Device (or, e.g., Service Provider operating the Identification Device) knows the prime numbers Pj and P2, it may reverse the algorithm and recover Ch and C_ID, as follows:
- the Identification Device may use the Euclidean Algorithm in conjunction with Pj and P2. to compute LI and L2, such that: KI and K2 may be defined as follows:
- the Identification Device then may proceed as follows:
- the Identification Device may XOR C with V as follows:
- the identification is complete. Recuperation of the Ch then may be used to authenticate the identification, to the extent that Ch should be exactly the same as the Ch sent to the Remote Entity.
- the example shown represents an extremely secure methodology for identifying a Remote Entity because the sensitive secrets, namely, the knowledge regarding how to factorize the SSN (namely ? ⁇ and P2) is only available at the Identification Device and not available to the Remote Entity (e.g., not stored in a token carried by the Remote Entity).
- any suitable mathematical (or other) manipulations or operations may be employed in the context of the present invention.
- the present invention further provides methods for identifying one or more Remote
- the Independent Arbitrator Entity may characterize a specific algorithm (or a plurality of algorithms) for each of the Remote Entities, and then distribute each algorithm to its respective Remote Entity; b) The Central Identification Device (e.g., operated by a Service Provider) may distribute one (or more) reversible algorithm to each of the Remote Entities; c) Each time a Remote Entity is to be identified, the Remote Entity may apply the
- Independent Arbitrator Entity's algorithm to a challenge (Ch) provided by the Central Identification Device thereby providing a first result Rl.
- the Remote Entity then may apply the Central Identification Device's reversible algorithm to the challenge Ch, to its identification data C ID, and to the said first result Rl , thereby computing a second result R2 (the Cipher).
- the Remote Entity then may transmit the second result R2 to the Central Identification Device.
- the Central Identification Device then may apply the reverse of the reversible algorithm to the received second result R2, thereby computing a presumed challenge Ch', a C ID, and a presumed first result Rl.
- the Identification Device then may compare the transmitted challenge Ch to the computed presumed challenge Ch'.
- the Central Identification Device may transmit the presumed first result Rl to an Independent Arbitrator Entity together with the Remote Entity's identification data (which may be C_ID or other data, for example a Remote Entity's Serial Number) and the challenge Ch.
- the Arbitrator Entity then may retrieve the specific algorithm transmitted from the specific Remote entity and apply the algorithm to the challenge Ch, thereby computing a true first result Rl .
- the Arbitrator Entity then may compare the true first result Rl with the presumed first result Rl and, if they are identical, the arbitrator entity may corroborate the identification to the Central Identification Device. Once the Central Identification Device has received the corroboration from the Arbitrator Entity, it may accept the presumed identification data
- F ARB* ASN which preferably is selected from a family of algorithms F AR ⁇ l, preferably by the means of a seed number (referred to herein as an Arbitrator Seed
- REAN Remote Entity's Arbitrator Number
- the REAN is preferably the result of the product of two large prime numbers, p'l and p'2, both of which may be congruent with 3(mod4). Hence the computed Rl may be different and specific for each transaction.
- the algorithm F_ARB 1 J ⁇ N is suitably applied to a Remote Entity's openly known number, for example, the Remote Entity's Serial Number or any other publicly known number associated with the Remote Entity, to generate the REAN (Remote Entity's Arbitrator Number), as follows:
- F_ARB 1 ASN (Serial Number) REAN.
- the second algorithm selected by the Arbitrator is referred to herein as F_ARB RE A N, which also preferably is selected from a family of algorithms by means of the previously obtained Remote Entity Arbitrator Number REAN (See Figure 1, block 3).
- an Arbitrator only needs to select one number, namely the ASN, which is suitably the same for all the cases belonging to such Arbitrator.
- the REAN is advantageously different and preferably dedicated for each Remote Entity, and the Rl is different for each transaction and inferred from the ASN to further enhance security.
- the Remote Entity may then apply the F ARB ⁇ RJ ⁇ N algorithm to Ch (and, optionally, to C ID), thereby getting a response Rl (see Figure 2, block 11), as follows: F_ARB REAN (CJD, Ch ) - Rl .
- the Remote Entity may then transmit Cipher R2 to an Identification Device (e.g., ID Node or System Administrator) (See Figure 2, block 13).
- the Identification Device may then receive Cipher R2 (see Figure 2, block 14).
- the Identification Device which knows the values of Pi and P2, then may non-repudiably identify the Remote Entity, without using any database, by applying the reverse of F_SYS ssn to R2.
- F _ 1 _SYS ssn is applied to R2, thereby retrieving the original arguments, namely, C ID, Ch' and Rl , as follows:
- Ch' is sufficiently identical to the Ch transmitted, then the CJD is validated as being authentic, e.g., an authentic Entity Identification Number (See Figure 2, blocks 15 and 16).
- Rl then may be preserved to refute repudiations of such transactions. That is, cases where the Remote Entity denies that he/she/it had a Cipher (e.g., R2), or, in other words, when the Remote Entity claims that a Cipher (e.g., R2) was fabricated by the Identification Device and/or the controller of such a device (See Figure 2, block 17).
- a Cipher e.g., R2
- the Identification Device may provide the Arbitrator with a Remote Entity's Serial Number, the Ch, the Presumed Rl, and, optionally, the CJD (see Figure 3, blocks 19,20 and 21).
- the Arbitrator may then apply the F_ARB 1 A g] ⁇ f algorithm to the Serial Number, thereby obtaining the REAN, as follows:
- the arbitrator may then determine whether the true Rl is identical to the Presumed Rl (see Figure 3, blocks 24 and 25). If Rl and the Presumed Rl are not identical, then R2 may be a fabrication (See Figure3, block 27). On the other hand, if Rl matches the presumed Rl, it may be concluded that the R2 is coming from an Authorized Remote Entity, because the Identification Device has no means with which to compute (fabricate) a true Rl (see Figure 3, block 26).
- the Remote Entity may utilize an algorithm F_ARB 2 RE A N, characterized by an Arbitrator by means of a REAN, to compute the transaction specific Rl, using the transaction specific Challenge Ch transmitted by the Identification Device (e.g., ID Node/ System Administrator), as follows: the Remote Entity may compute:
- Rl C' l o o o o o o o o C' n .
- step F_ARB 2 RE N (Ch ) Rl thereby may be accomplished.
- a System Seed Number selected by an administrator, may be used to infer a SM (System Module, as discussed above).
- the Remote Entity may make the following computations:
- ⁇ n+l ⁇ 2 n ( mod SM )
- Cipher (R2) message then may be computed as follows:
- R2 [(CJD ° CH)] ® C] o T n+m .
- step F_SYS ssn (Ch ) R2 thereby may be accomplished.
- Cipher should be different from any prior Cipher (R2), to the extent that the Ch is different from any prior Ch transmitted to a particular Remote Entity.
- the Remote Entity may transmit the Cipher R2 to an Identification Device (e.g., ID Node/System Administrator) and, because the Identification Device knows the prime numbers Pi and P2, the Identification Device may reverse the algorithm and recover Ch and CJD.
- the Identification Device e.g., ID Node/System Administrator
- the Identification Device may use the Euclidean
- Tn+m-1 ZjK + Z 2 K ⁇ ; and, applying the same procedure, compute: Tn+m-2 and so on, obtaining all the Ti until TQ is recuperated.
- the identification may be complete.
- the recuperation of Ch then may be used to authenticate the identification, to the extent that Ch should be exactly the same as the Ch sent to the Remote Entity.
- the Identification Device e.g., ID Node/System Administrator
- the Identification Device may provide the Arbitrator with the Remote Entity's Serial Number, the transaction Ch, the presumed Rl and, optionally, the CJD.
- the Arbitrator then may apply the F_ARB R£ J S T algorithm to Ch and, optionally, to CJD, thereby obtaining the true Rl , as follows: a) the Arbitrator may compute:
- the Arbitrator may then check whether the true Rl is identical to the Presumed Rl claimed by the Identification Device (e.g., ID Node/system administrator). If they do not match, the R2 is a fabrication. On the other hand, if the two numbers match, it is confirmed that the R2 is from the Remote Entity because the Identification Device has no means with which to compute (fabricate) a true Rl .
- the Identification Device e.g., ID Node/system administrator
- the example shown represents an remarkably secure methodology to identify a Remote Entity.
- the sensitive secrets e.g., the knowledge on how to factorize the SSN, is available only to the Identification Device (e.g., ID Node/ System Administrator) and is not available to the Remote Entities (e.g., not in their tokens).
- the methods and algorithms described above may be used, but, instead of having the Identification Device send a challenge (Ch) to the Remote Entity, the Remote Entity may use the Cipher's Generation Time.
- this type of time-based variable will be referred to herein as Generation Time, or Gtime (see Figure 4, block 10b).
- Gtime Generation Time
- a Remote Entity may proceed as in Figure 4, illustrating a non- repudiable, non-trackable, one-way identification method.
- the Remote Entity may transmit a message, which identifies the Remote Entity, to the Identification Device (e.g., ID Node, or one of various ID Nodes of a particular Service Provider), and this ends the protocol. Accordingly, during the time that the identification is being made on-line, both sides, Remote Entity and Identification Device, know the corresponding Gtime/Reception Time (see Figure 4, block 14b) and, consequently, the Identification Device may verify the identification (See Figure 4, blocks 15b and 16b). If the Identification is not on-line, the Generation Time used in the computation may be communicated openly to the Identification Device.
- the Identification Device e.g., ID Node, or one of various ID Nodes of a particular Service Provider
- two successive identification procedures may be accomplished during the same identification process (see Figure 5).
- the time elapsed between the two identification procedures also may be determined by the Identification Device (see Figure 5, block 19d), which will signal/ trigger the Remote Entity to send a new Cipher. Because the time elapsed is set by the Identification Device, this process avoids the possibility of an impostor using two pre-recorded Ciphers in an attempt to defraud the system. Hence, measuring the Absolute Value of the drift difference (see Figure 5, block 27d) the Identification Device can overcome the drift problem without compromising security.
- Another preferred exemplary implementation of the methods of the present invention comprises a process similar to that described in Figure 5, but instead of using the Gtime a
- Remote Entity may use a Remote entity's specific function of the Gtime, referred to herein as F JJRE(Time), which preferably is a linear function.
- F JJRE(Time) a Remote entity's specific function of the Gtime
- the Identification Device e.g., ID Node/ System Administrator
- F_T_RE(Time) a Database
- the Identification Device may use a database anyway, it may be convenient to preserve the RE_Time and RTime of the previous transaction (referred to herein as RE_Time_pre and RTime_pre) in a database available to the Identification Device. This is in order to update the drift while the RE_cte value is being updated, which absorbs the drift as is shown in Figure 6.
- the Identification Device after receiving the RE Time embedded in the Cipher and registering the RTime (Reception Time), will compare the difference:
- This difference should be less than a tolerance value.
- the tolerance value may be a function (FTolerance) of the absolute value of the difference between RTime and Rtime_pre, as follows: FTolerance(RTime - RTime_pre).
- the methods of the present invention may include the addition of encryption steps.
- the sequential order of the steps or sub-steps illustrated herein are used only to explain the methodology presented, and do not limit or define the scope of the invention. Accordingly, slight variations in the implementation and/or sequential order the method steps described herein do not represent a departure from the spirit and scope of the invention.
- the invention has been described herein using a general method for identification, many possible implementations of the methods presented by the invention are possible and remain within the scope of the invention. For example, these methods may be implemented in part wherein the Remote Entities are tokens or other portable devices (e.g., smart cards), or are the carriers of such devices. Moreover, the Identification Devices described herein may be in the form of PC's, ATMs, kiosks, or the like. Furthermore, the above- described methods may be masked or otherwise embedded into chips, and would not represent a departure from the spirit of the present invention.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
Claims
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IL12210697 | 1997-11-04 | ||
IL122106A IL122106A (en) | 1997-11-04 | 1997-11-04 | Method and algorithms for identification and validation |
PCT/IB1998/001834 WO1999027676A2 (en) | 1997-11-04 | 1998-11-04 | Methods and apparatus for the secure identification and validation of things and events |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1031260A2 true EP1031260A2 (en) | 2000-08-30 |
EP1031260A4 EP1031260A4 (en) | 2001-03-28 |
Family
ID=11070814
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP98951640A Withdrawn EP1031260A4 (en) | 1997-11-04 | 1998-11-04 | Methods and apparatus for the secure identification and validation of things and events |
Country Status (5)
Country | Link |
---|---|
EP (1) | EP1031260A4 (en) |
AU (1) | AU9757898A (en) |
CA (1) | CA2308474A1 (en) |
IL (1) | IL122106A (en) |
WO (1) | WO1999027676A2 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7013393B1 (en) | 1999-12-21 | 2006-03-14 | Pierre Stevens | Universal intelligent card for secure access to system functions |
EP1668448A2 (en) | 2003-09-12 | 2006-06-14 | RSA Security Inc. | System and method providing disconnected authentication |
GB0514492D0 (en) | 2005-07-14 | 2005-08-17 | Ntnu Technology Transfer As | Secure media streaming |
US10075452B2 (en) | 2016-02-18 | 2018-09-11 | Comcast Cable Communications, Llc | Distributed content uploading and validation |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0522473A2 (en) * | 1991-07-08 | 1993-01-13 | Mitsubishi Denki Kabushiki Kaisha | Cryptographic identity verification method and apparatus |
EP0770953A2 (en) * | 1993-05-05 | 1997-05-02 | Addison M. Fischer | Personal date/time notary device |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4326098A (en) * | 1980-07-02 | 1982-04-20 | International Business Machines Corporation | High security system for electronic signature verification |
GB2146815A (en) * | 1983-09-17 | 1985-04-24 | Ibm | Electronic fund transfer systems |
US5010571A (en) * | 1986-09-10 | 1991-04-23 | Titan Linkabit Corporation | Metering retrieval of encrypted data stored in customer data retrieval terminal |
US5349643A (en) * | 1993-05-10 | 1994-09-20 | International Business Machines Corporation | System and method for secure initial program load for diskless workstations |
EP0720796B1 (en) * | 1993-09-20 | 1997-07-16 | International Business Machines Corporation | System and method for changing the key or password in a secure distributed communications network |
JP3263878B2 (en) * | 1993-10-06 | 2002-03-11 | 日本電信電話株式会社 | Cryptographic communication system |
US5491750A (en) * | 1993-12-30 | 1996-02-13 | International Business Machines Corporation | Method and apparatus for three-party entity authentication and key distribution using message authentication codes |
US5790667A (en) * | 1995-01-20 | 1998-08-04 | Matsushita Electric Industrial Co., Ltd. | Personal authentication method |
JPH0950465A (en) * | 1995-08-04 | 1997-02-18 | Hitachi Ltd | Electronic shopping method, electronic shopping system and document authentication method |
-
1997
- 1997-11-04 IL IL122106A patent/IL122106A/en not_active IP Right Cessation
-
1998
- 1998-11-04 AU AU97578/98A patent/AU9757898A/en not_active Abandoned
- 1998-11-04 CA CA002308474A patent/CA2308474A1/en not_active Abandoned
- 1998-11-04 WO PCT/IB1998/001834 patent/WO1999027676A2/en not_active Application Discontinuation
- 1998-11-04 EP EP98951640A patent/EP1031260A4/en not_active Withdrawn
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0522473A2 (en) * | 1991-07-08 | 1993-01-13 | Mitsubishi Denki Kabushiki Kaisha | Cryptographic identity verification method and apparatus |
EP0770953A2 (en) * | 1993-05-05 | 1997-05-02 | Addison M. Fischer | Personal date/time notary device |
Non-Patent Citations (1)
Title |
---|
See also references of WO9927676A2 * |
Also Published As
Publication number | Publication date |
---|---|
WO1999027676A3 (en) | 1999-09-02 |
EP1031260A4 (en) | 2001-03-28 |
IL122106A (en) | 2010-11-30 |
AU9757898A (en) | 1999-06-15 |
WO1999027676A2 (en) | 1999-06-03 |
IL122106A0 (en) | 1998-12-06 |
CA2308474A1 (en) | 1999-06-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6957185B1 (en) | Method and apparatus for the secure identification of the owner of a portable device | |
US11100743B1 (en) | Blockchain-based election system | |
JP2777060B2 (en) | Authentication method of portable object by offline terminal and corresponding terminal | |
US6192349B1 (en) | Smart card mechanism and method for obtaining electronic tickets for goods services over an open communications link | |
US8315948B2 (en) | Method and device for generating a single-use financial account number | |
US7844550B2 (en) | Method and device for generating a single-use financial account number | |
US4797920A (en) | Electronic funds transfer system with means for verifying a personal identification number without pre-established secret keys | |
CA2816996C (en) | Portable security transaction protocol | |
JP2000357156A (en) | System and method for authentication sheet distribution | |
CA3184856A1 (en) | Method, participatant unit, transaction register, and payment system for managing transaction data sets | |
US8631475B1 (en) | Ordering inputs for order dependent processing | |
WO1999027676A2 (en) | Methods and apparatus for the secure identification and validation of things and events | |
US7110858B2 (en) | Object identification uses prediction of data in distributed network | |
KR100830969B1 (en) | Method and System for Implementing Financial Transactions Using OTP | |
WO1996041316A2 (en) | Off-line compatible electronic cash method and system | |
KR20070104026A (en) | Method and system for generating random numbers for object oriented otp | |
EP4437683A1 (en) | Digital currency | |
JP2005252349A (en) | Certifying simulated zero-knowledge method of |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20000522 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20010208 |
|
AK | Designated contracting states |
Kind code of ref document: A4 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE |
|
RIC1 | Information provided on ipc code assigned before grant |
Free format text: 7H 05K 1/00 A, 7H 04L 9/32 B |
|
17Q | First examination report despatched |
Effective date: 20010522 |
|
GRAH | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOS IGRA |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20030603 |