WO2002078199A2 - A method and system for remotely authenticating identification devices - Google Patents
A method and system for remotely authenticating identification devices Download PDFInfo
- Publication number
- WO2002078199A2 WO2002078199A2 PCT/IL2002/000236 IL0200236W WO02078199A2 WO 2002078199 A2 WO2002078199 A2 WO 2002078199A2 IL 0200236 W IL0200236 W IL 0200236W WO 02078199 A2 WO02078199 A2 WO 02078199A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- authentication
- card
- datagram
- signal
- server
- Prior art date
Links
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B32—LAYERED PRODUCTS
- B32B—LAYERED PRODUCTS, i.e. PRODUCTS BUILT-UP OF STRATA OF FLAT OR NON-FLAT, e.g. CELLULAR OR HONEYCOMB, FORM
- B32B37/00—Methods or apparatus for laminating, e.g. by curing or by ultrasonic bonding
- B32B37/14—Methods or apparatus for laminating, e.g. by curing or by ultrasonic bonding characterised by the properties of the layers
- B32B37/16—Methods or apparatus for laminating, e.g. by curing or by ultrasonic bonding characterised by the properties of the layers with all layers existing as coherent layers before laminating
- B32B37/18—Methods or apparatus for laminating, e.g. by curing or by ultrasonic bonding characterised by the properties of the layers with all layers existing as coherent layers before laminating involving the assembly of discrete sheets or panels only
- B32B37/182—Methods or apparatus for laminating, e.g. by curing or by ultrasonic bonding characterised by the properties of the layers with all layers existing as coherent layers before laminating involving the assembly of discrete sheets or panels only one or more of the layers being plastic
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
- G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
- G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
- G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
- G06K19/07745—Mounting details of integrated circuit chips
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
- G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- 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
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B32—LAYERED PRODUCTS
- B32B—LAYERED PRODUCTS, i.e. PRODUCTS BUILT-UP OF STRATA OF FLAT OR NON-FLAT, e.g. CELLULAR OR HONEYCOMB, FORM
- B32B2305/00—Condition, form or state of the layers or laminate
- B32B2305/34—Inserts
- B32B2305/342—Chips
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B32—LAYERED PRODUCTS
- B32B—LAYERED PRODUCTS, i.e. PRODUCTS BUILT-UP OF STRATA OF FLAT OR NON-FLAT, e.g. CELLULAR OR HONEYCOMB, FORM
- B32B2309/00—Parameters for the laminating or treatment process; Apparatus details
- B32B2309/60—In a particular environment
- B32B2309/68—Vacuum
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B32—LAYERED PRODUCTS
- B32B—LAYERED PRODUCTS, i.e. PRODUCTS BUILT-UP OF STRATA OF FLAT OR NON-FLAT, e.g. CELLULAR OR HONEYCOMB, FORM
- B32B2425/00—Cards, e.g. identity cards, credit cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2129—Authenticate client device independently of the user
-
- H—ELECTRICITY
- H01—ELECTRIC ELEMENTS
- H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
- H01L2924/00—Indexing scheme for arrangements or methods for connecting or disconnecting semiconductor or solid-state bodies as covered by H01L24/00
- H01L2924/0001—Technical content checked by a classifier
- H01L2924/0002—Not covered by any one of groups H01L24/00, H01L24/00 and H01L2224/00
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- the present invention relates to authentication methods, hi one aspect thereof, the invention relates to a method and system for authenticating an identification devices, such as a self-powered card (hereinafter referred to as SPC).
- SPC self-powered card
- Authentication is the process of verifying an object or message to ensure that the object or message are what they purport to be and/or were not tampered with. For example, authenticating an e-mail message can check that it was signed using a method that can only be performed by the supposed sender.
- Encryption is the conversion of data into a form that cannot be easily understood by unauthorized people.
- Decryption is the process of converting encrypted data back into a form, in which it can be (at least partly) understood.
- Un-encrypted data is usually called
- Cipher-text Plain-text while encrypted data is referred to as Cipher-text.
- the encryption and decryption are subject to a Key, used for conversion between one form and the other.
- Cryptography is the art of protecting information by encrypting it into an unreadable format (i.e. cipher-text). In some implementations, only those who possess a secret key can decrypt the message into plain text. As the Internet and other forms of electronic communication become more prevalent, electronic security is becoming increasingly important. Cryptography is therefore used to protect data such as e-mail messages, credit card information, and so forth.
- Symmetric-key cryptography is an encryption method in which the sender and receiver of a message share a single, common key, which is used to encrypt and decrypt the message. Symmetric-key systems are simpler and faster, but their main drawback is that the two parties must somehow exchange the key in a secure way. Also, the receiver can pretend (to third parties) to be the sender, using the key.
- the most popular symmetric-key system is the DES (Data Encryption Standard), also described below.
- Asymmetric-key cryptography is a cryptographic system that uses two keys - one key for encryption and another key for decryption.
- Public-key cryptography is an asymmetric-key cryptography. According to this method, one key is known to a plurality of persons (and hence called Public-key), while the other key is known only to one person (and hence called Private-key).
- An important feature of the public key system is that the public and private keys are related in such a way that once the public-key is used to encrypt a message, only the corresponding private key can be used to decrypt it. Theoretically, it is impossible to deduce the private-key from the corresponding public-key.
- a sender wants to send a secure message to a recipient, he uses the recipient's public-key to encrypt the message, and the recipient uses his corresponding private-key to decrypt it. That way, the recipient of a data can be sure that the data comes from a purported sender (if the key was not stolen%), and the sender can be sure that the data reaches the right destination.
- Pseudo-random numbers are numbers having properties similar to those of random numbers, for example, certain distribution properties and lack of (easily discernible) relationship between consecutive numbers. True, unbiased, random numbers are difficult if not impossible to generate. Pseudo-random numbers can be generated using computing machinery means, software and hardware. These means are usually called “Random-number generators", or RNG. Both linear and non-linear RNGs are known, with linear RNGs having a greater predictability problem.
- DES Data Encryption Standard
- IBM IBM algorithm that was further developed by the U.S. National Security Agency. It uses the block cipher method, which breaks the text into 64-bit blocks before encrypting them.
- DES3 also called Triple DES
- Triple DES is an enhancement to DES that provides more security than standard DES, which uses only one 56-bit key. DES3 may be also be used for generating random numbers.
- a Hash function is a transformation that converts a number (or other data representation) from a large space to a (typically) smaller space, typically with an even distribution.
- a hash function is used to convert a large string of fixed or varying length into a short value of a fixed size, which is called the Hash value of the string.
- One property of many Hash functions is that they are truly unreversible in that the original number cannot be reconstructed from the Hash value. This can be useful for protecting against untrustworthy employees. Merely encrypting the data may not be enough if the employee can steal the keys for decryption. It is often desirable that the computational effort be relatively moderate. Providing an even distribution may be useful in reducing the number of collisions (e.g., different inputs with same has value. Examples of well-known Hash functions are MD2 and MD5.
- E-wallet is a recent effort to provide the electronic equivalent of a wallet (or better than equivalent) for e-commerce transactions and/or for physical transactions.
- Many , implementations are known.
- a digital wallet e-wallet holds digital money that is purchased similar to travelers-checks, a prepaid account, or it can contain credit card information.
- the wallet may reside, for example, in a user's machine (including an electronic device/card) or on the servers of a Web payment service. When stored in a user's machine, the wallet may use a digital certificate for identifying a cardholder.
- SSL Secure Sockets Layer
- HTTP Hypertext Transfer Protocol
- TCP Transport Control Protocol
- SSL is included as part of both the Microsoft and Netscape browsers and many Web server products.
- the "sockets" part of the term refers to the sockets method of passing data back and forth between a client and a server program in a network or between program layers in the same computer.
- SSL uses the public-and-private key encryption system provided by
- CRC Cyclic redundancy checking
- a sending device applies a 16- or 32-bit polynomial to a block of data that is to be transmitted and appends the resulting cyclic redundancy code (CRC) to the block.
- a receiver applies the same polynomial to the data and compares its resulting CRC with the result appended by the sender. If they agree, the data has probably been received successfully. If not, the sender can be notified to resend the block of data.
- One Time Code is a method by which whenever an authentication trial is initiated, a unique code, single use (or possibly small number of uses), is provided for authentication.
- BACKGROUND The Internet, and the World Wide Web (WWW) in particular, has grown in popularity in recent years.
- WWW World Wide Web
- many computer users are still somewhat leery of conducting sales transactions over the Web especially because credit cards are involved, along with the associated fear of widespread and unchecked dissemination of the credit card numbers.
- These same users may also be leery of conducting non-Internet related sales transactions using credit cards.
- One worry is that After all, anyone can steal a credit card number and use it later for unauthorized purchases.
- authentication may be useful, for example, opening a door to a secured location, buying commodities, entrance (and staying i ) a secret facility, e-commerce, and logging in to a system.
- an identification card such as credit or social security
- the authentication requirements are so high that the authentication process requires biometric analysis.
- credit cards are used for authentication. They comprise a magnetic stripe that comprises the ID of the owner of the credit card and some additional details.
- a conventional credit card provides relatively poor authentication, since its magnetic strip can be copied and an associated secret password (e.g., PIN) stolen rather easily.
- the second one is "something you know”; namely a password and the third element is "having a witness”; namely the merchant's presence.
- These elements exist whenever a buyer is actually where the transaction is about to take place; e.g. in a shop.
- the card's details are compared with the card's details contained in the card's issuer database. Verifying the cardholder is carried out by comparing his signature to the one on the card and/or using some sort of identifying card; e.g. a driving license. Since the card issuer confirms the card details and the transaction itself, the card issuer bears the consequences in case of a fraud.
- the problem arises from the fact, that in a case of a "non-present card" transaction, there are generally two unsecured and parallel channels, which contribute to the risk of fraud.
- the first channel relates is the transaction channel itself. Whenever a cardholder wishes to carry out a transaction, he is asked by the merchant to give him details regarding the card and also his ID number. The merchant forwards these details to the card issuer (usually by phone) and upon approval of the transaction by the card issuer, the transaction is given a special code.
- the second channel is the authentication phase of the card by conventional methods, such as giving a password to the card issuer or by using a conventional electronic device.
- the problem in such cases is that the card issuer can not be sure that the specific code given to the transaction relates to the corresponding authenticated card.
- a smart card includes a built-in microprocessor and memory used for identification and/or financial transactions.
- a smart card is currently used in conjunction with a special electronic reading device. When such a card is inserted into a reader, it transfers data to and, and receives from, a central computer. It is more secure than a conventional magnetic strip card and can be programmed to lock if the wrong password is entered too many times.
- a conventional authentication system that involves a smart card comprises the following elements:
- a card (may be called also "authentication token"), which comprises at least the ID of the card and a secret code, which is usually unique for each card; and
- An authentication server which comprises the details of each of the cards, their owner and their secret code.
- the authentication process in this case is carried out as follows:
- the one-time code mechanism usually generates pseudo-random numbers, which from an outsider point of view, are random numbers. However, in some conventional systems the numbers can be predicted and abusively utilized, since the smart card and the authentication servers use the same numbers' generator.
- An aspect of some embodiments of the invention relates to controlling an authentication process, for example, so as to protect a card merchant and/or a card user from fraud.
- the protection comprises encrypting transmissions to a remote authentication server, for example to prevent tampering.
- the encryption comprises signing with merchant related information, for example, so the authentication process can be reliably linked to both a card and a merchant.
- the encryption comprises signing the transmission at the user, for example to include user related and merchant page related information or a timestamp.
- the merchant signature is provided by the authentication server or an associated entity.
- the encryption is provided by software embedded or otherwise linked to a WWW page used by the user to access the merchant.
- the embedded software will work only if the merchant is online and responding correctly.
- the merchant sends a one time code to the user, for each session and expects the code, hash thereof and/or a signed form thereof to be returned by the user.
- the user can be verified by the merchant.
- the code may be provided, for example using the embedded software.
- protection is provided by generating codes for an authentication card and then destroying initial numbers used to generate the codes.
- the codes used by a card are pre-set at the time a card is manufactured and no new codes are generated nor is there a way to generate them once the initial numbers are destroyed.
- protection is provided by the authentication server generating a simple authentication answer, without a reason.
- the history of authentication of a particular card is used to assist authentication. For example, a more restrictive authentication method is used for initial authentication, but if a consecutive authentication attempt is made with similar parameters (e.g., but with a counter that is increased by one or a small number), it may succeed.
- the number of codes skipped between authentication attempts is used as an indication of the validity of an attempt.
- various decisions may be made according to the results of the Authentication process, for example, if to freeze a card, allow a second attempt, warn a merchant and or freeze a merchant (e.g., if many authentication errors come with a same merchant designation).
- An aspect of some embodiments of the invention relates to a method of signal detection for acoustic signals.
- the method employs a tradeoff which allows less processing to be used, while allowing some types of errors.
- the method comprises correlating Hubert transforms of expected FSK frequencies, rather than correlating the frequencies themselves. This may allow various delays in an input signal to be correct for.
- a sinusoidal signal is represented as an analytic signal using a Hubert transform. It is then correlated with itself and integrated over an interval. The total power and/or other property of this integral is indicative of whether a signal is present or noise.
- a method of authenticating, using an authentication server, the use of an authentication device over a communication network via an intermediate communication device comprising: receiving an authentication datagram by said intermediate device; protecting said datagram by said intermediate device, by at least one of changing, adding to, encrypting and signing of said datagram; and forwarding said datagram to said authentication server for authentication.
- said intermediate device comprises a vendor WWW site.
- protecting comprises adding a signature associated with said vendor to said datagram.
- protecting comprises encrypting said datagram.
- said intermediate device comprises a user computing device.
- said computing device adds a time stamp to said datagram.
- said computing device adds a vendor-associated information item to said datagram.
- said computing device encrypts said datagram.
- said encryption uses a one time code. Alternatively or additionally, said one time code is provided by a vendor for a particular session with said user.
- said user computing device uses an embedded software component for said protecting.
- said embedded software comprises an ActiveX component.
- said component is cached on said user device.
- said component requires a property value provided by a vendor to operate.
- communication between said intermediate device and said server uses a secure connection.
- a method of authentication of an authentication datagram by a remote authentication server comprising: sending an encrypted datagram by secure computer communication from a vendor software to said remote authenticator; comparing said datagram or a hash thereof to a hash table at said server; and generating a binary validation answer by said server without an associated explanation.
- a method of authentication of an authentication datagram by a remote authentication server comprising: sending an encrypted datagram by computer communication from an authentication device to said remote authentication server; searching, at said server, for a hash value matching said datagram or a hash thereof; and generating a validation answer by said remote authentication server, responsive to said search, wherein, said datagram includes a secret code and wherein said secret code exists only on said authentication device.
- said authentication device includes a plurality of secret codes that are generated to appear unrelated.
- a method of generating a code set for an authentication device comprising: providing a code generating software; providing at least one seed code for said software; generating said code set using said software and said seed; destroying said seed immediately after generating said code set; and storing said code set or an indication thereof on an authentication device.
- the method comprises generating hash values for said code set.
- the method comprises generating a second set of hash values for said code set, using a different hash function for said second set.
- a method of communication between a vendor and a user using an authentication device comprising: generating a one time code for the user for a session; receiving an authentication datagram from said user; and passing on said datagram for verification by a remote authentication server if at least an indication of said one time code that matches said user is provided with said datagram.
- the method comprises signing said datagram using said one time code by said user.
- a method of remote validation comprising: receiving an authentication datagram by an authentication server from a remote authentication device; matching said datagram or a hash of said datagram to a table; calculating a counter value from a matcliing position in said table; and validating said authentication datagram based on an increase in said counter over a previous counter being within a certain limit.
- the method comprises: failing said authentication based on said increase being too large; and allowing a subsequent authentication based on a further increase of said subsequent validation being below a second threshold.
- said thresholds are the same.
- said second threshold is smaller than said certain threshold.
- said counter comprises an ordinal position in said table that is not apparently related to a series of generated random numbers.
- a method of detecting a transmission of an acoustic multitone FSK signal comprising: receiving an acoustic signal; converting the signal into a Hilbert-transform representation of the signal correlating said converted signal with at least one reference signal representing at least one expected frequency in said FSK signal; integrating said correlation over an interval; and determining if a signal is present, based on a thresholding of a result of said integrating.
- the method comprises further determining if a detected signal has a frequency within a certain frequency range.
- the method comprises further determining if a detected signal has a signal to noise ratio within a certain signal to noise ratio range.
- the method comprises resampling said signal after said determining.
- said threshold is noise dependent of the received signal.
- the method comprises calculating said interval based on a hardware characteristic of a producer of said acoustic signal.
- Fig. 1 schematically illustrates a process for detecting existence of forged devices, according to one embodiment of the invention
- Fig. 2 schematically illustrates an authentication scheme of a device, according to an exemplary embodiment of the invention
- FIG. 3 schematically illustrates using an ActiveX control to secure Internet transaction, according to a preferred embodiment of the invention
- Fig. 4A is a flow-chart of an authentication process, according to one embodiment of the invention
- Fig. 4B is a flow-chart of an authentication process, according to another embodiment of the invention.
- FIG. 5 A schematically illustrates the structure of a multitone FSK signal according to an exemplary embodiment of the invention
- Fig. 5B schematically illustrates a detector for a multitone FSK signal, according to an exemplary embodiment of the invention
- Fig. 6 is a flow chart illustrating the process of detection and estimation of multitone FSK signal, in accordance with an exemplary embodiment of the invention
- Fig. 7 schematically illustrates a method for decoding a multitone FSK signal, in accordance with an exemplary embodiment of the invention.
- An example of an identifying device is a self-powered electronic card (SPC) that performs wireless communication with a standard PC or telephone without using a card reader.
- the card transmits a user identification code to a PC, a mobile, or a regular phone, enabling online authentication and physical presence in online transactions.
- non- card devices such as statues and pens, may be provided as well.
- the authentication system may be designed to be implemented on various computer or telephony networks, such as the Internet, extranets, and INR systems.
- the card may also support payment card legacy systems, such as magnetic stripe readers. It can be implemented, for example as a standard credit card or a bankcard, a membership card, or a gift certificate, and works both on the Internet and in the offline world. Additionally, a conventional smart card's electronic circuit (e.g. an electronic microchip) may be embedded in the SPC.
- payment card legacy systems such as magnetic stripe readers. It can be implemented, for example as a standard credit card or a bankcard, a membership card, or a gift certificate, and works both on the Internet and in the offline world.
- a conventional smart card's electronic circuit e.g. an electronic microchip
- the cardholder squeezes a button provided on the card, while holding the card relatively close (e.g., approximately 3 inches from) to the front of the PC's microphone.
- the card then sends a sonic transmission of a unique, one-time code to the device's microphone.
- a client software which may be for example a communications layer embedded in a web page, receives this encrypted one-time code.
- the communication layer relays the code, unaltered (or as described below, for example, encoded and/or with data added), to a remotely located Authentication server for authentication.
- Current versions of the client software are generic database program based software, which are based on, but not limited to, Microsoft SQL and Oracle, for example.
- the card in some embodiments of the invention, converts PCs or telephones into point of sale terminals, enabling secure Intemet shopping, banking, and financial account services.
- the user software may be configured to receive the signal of an activated ComDot card (e.g., a card as described herein), launch a web browser and visit a specific URL, such as that of the card issuer.
- the card may serve as a user authentication, loyalty and secure transaction system, based around a credit card sized layer of electronic circuitry. This circuitry may be powered by an on-card battery, and activated by a flat switch, embedded in a standard credit card.
- a communication layer (embedded in the Web site for example as an ActiveX control or JNI plug-in) may be cached into the user's browser.
- the communication layer receives the signal from the card and authenticates the card through communication with a server running authentication software.
- the information transmitted by the card is received by a client software application, running on a Windows-compatible PC, or as part of a PC-based telephony Interactive Voice Response (IVR) or Computer-Telephony (CTI) system.
- IVR Interactive Voice Response
- CTI Computer-Telephony
- the client software application upon verifying that a complete signal was received, sends the received signal- via a secure HTTPs or SSL network link- to the Authentication Server.
- no decryption of the transmitted signal is performed on the client.
- encryption by the client is a separate step from using an SSL link, as it is performed by different software units, over which different degrees of control are available and different degrees and types of attacks by a hacker (or other malicious person) maybe perpetrated.
- the card's signal is optionally sent to the authentication server for example by the client software or an ActiveX control.
- the server software analyses this signal, then reports to the card issuer's or third party's web server as to whether the signal in question comes from a Valid (i.e. active card) or Invalid source.
- the authentication system employs unique, one-time cryptographic codes for enhanced security.
- This one-time code is generated and encrypted by the card, and remains encrypted until it reaches the authentication server software.
- no decryption of the data, which is received from the card, is performed in the authentication server.
- the card when an e-wallet, merchant payment Web site or gateway, or other payment middle ware is equipped with a software client, the card authenticates cardholders to their payment card issuers and e-merchants, potentially reducing the problem of on-line fraud. Because the presence of a card in transactions can be proven (to some extent), cardholders shop online without fear of credit card theft.
- additional protection steps may be taken. For example, using a random generator with three keys with values unique to each device, using a CRC for validating that transferred information have not been changed and/or different encryption functions and pseudo-random numbers for each card.
- a Datagram structure used by the card maybe as follows: - Header (not encoded)
- a card is authenticated on the Internet using the following process: 1. The user activates the card by pressing the built-in button.
- the card takes a counter value stored on internal, non-erasable memory and uses it as a seed value that is DES3 encrypted. Then it transmits an acoustic signal carrying an encrypted message (e.g., the counter, a card ID, a time stamp and/or a transaction detail).
- an encrypted message e.g., the counter, a card ID, a time stamp and/or a transaction detail.
- the PC's software receives the signal and uses the contained ED AC packets to ensure that the message is viable and has not been interrupted, and to correct errors if any. If the message is verified, the PC strips off the EDAC and sends the message to the authentication server without it being decrypted by the PC.
- the authentication system is optionally designed to work with a secure client-server communications link such as HTTPs or SSL.
- the message is first transmitted to a client site, for example a vendor site, where it is optionally not decrypted either before having information optionally added, optional encryption applied and being transmitted to an authentication server.
- the Authentication Server Software receives the message and performs a hash function on it. The output of this hash function is compared to a database of hash values maintained for each card. In an exemplary embodiment of the invention, only hash codes for the specified card are searched in the database. This feature is possible since the card ID number is also transmitted from the card to the Authentication server, thus allowing the server to limit the search process to a portion of the database, which corresponds to the specific card from which the transmission was received. If the hash function output of the received message appears in the database, the Authentication server reports to the card issuer's web server that the activated card is 'Valid'.
- a card is authenticated on the telephone using the following process:
- a cardholder dials an enabled telephony service.
- An Interactive Voice Response and/or Computer-Telephony system answers the call, and the cardholder is prompted to activate his card.
- the client application in this case the IVR and/or CTI application
- receives the card transmission and optionally forwards it to the Authentication Server (or a vendor site), where card authentication is optionally performed.
- Authentication Server or a vendor site
- telephony card authentication is optionally performed using a hash function process similar to that of the Internet cards.
- the authentication server's Valid or Invalid' indication is forwarded to the IVR and/or CTI system, which can, for example, admits cardholders to its telephony system, or requests card re-activation, according to its login policies.
- the communication layer is downloaded and installed by the user, typically in tandem with additional software provided by the card issuer (the communication layer could even be offered as a screen saver). Once installed, the communication layer runs in the background, waiting for a signal from the card.
- This persistently resident, "always on” implementation may be used, for example, for "electronic loyalty” applications, enabling one-click launch access to personalized web services.
- the persistently resident communication layer/tray application connect to the network, launch a browser, go to a specific URL, authenticate entry to the personalized service, and present the user with a personalized web service in a manner that is both convenient and secure.
- the communication layer's is implemented in a small size, which allows implementation in a Web page embeddable, for example, ActiveX or JNI-plug-in format.
- a Web page embeddable for example, ActiveX or JNI-plug-in format.
- Implementation in Active X, Netscape Plug-In, or in Java is useful for embedding the communication layer in web pages for automatic loading to users who visit the equipped Web site.
- a first-time user would simply go to a particular card issuer web page in which the communication layer is embedded, and then activate the device. Possibly, no conscious user decision to download or install is required.
- Authentication server The Authentication Server software can be implemented on a PC system running a
- the card will be ISO 7816 and ISO 7810 credit card tested, for example, by Visa certified labs. These tests include torsion testing, involving 1,000 bends of the card. The tests also include exposure to heat, cold, water and acids. Card security
- the card is secured physically and/or logically in order to prevent access to its secured data.
- Logical security is optionally achieved by encrypting the card's 'Secret User ID' and counter value using the DES 3 encryption technique.
- the card's public ID is transmitted without encryption.
- the electronic circuit is optionally secured by its placement as the middle of five plastic layers.
- the two layers of plastic on either side of the electronics layer, and the card's lack of external connectors constitute a degree of physical security. Additionally, once the data is written to a card EPROM, the read and write fuses are burned, to prevent accessing the written information.
- the encryption used in the card is 2 key DES3 algorithm.
- each card has two unique keys. These keys are randomly generated during the manufacturing process, for example, by a statistically safe, random generation mechanism. The keys are generated and written directly onto the card's nonerasable memory, and, as a security caution, are never stored outside of the card.
- the hash table is generated on the card and read off during manufacture. Then various fuses on the card may be destroyed, for example physically, or by providing the card with a suitable command, for example, to erase the hash table.
- the codes are prepared for particular customers, for example, so each customer can use his codes for validation.
- the customer prepares the codes and only a hash is provided to the authentication server. The customer may then load the cards that he distributes, with the desired codes and/or hash values thereof. By providing the customer with a different hash value, the authorization server can allow the customer to perform his own validation, without compromising the validation at the authentication server.
- the card creates and encrypts a onetime code every time the card is activated.
- the encrypted data is, for example, 64 bits in length and contains, for example, two or more fields; the 'secret card ID' and the Counter value. After each activation of the card the counter value is optionally incremented, making each transmitted code unique. Alternatively, a same one time code may be reused, for example, within 1 minute.
- EDAC electrospray 10.1.
- this information is transmitted not encrypted in order to verify that transmitted message is complete and to correct any error that may exist.
- the clients may be advised to use a second factor of authentication in tandem with the first factor token authentication.
- the second factor may be, for example, a PIN/password, secret question, voice verification, or other preferred authentication methods.
- the described method does not put limitations on the type of second factor authentication technique that can be employed.
- the server authenticates a cardholder using a comparison function.
- the hashed version of the card's encrypted data bit stream is searched for in the hash database.
- this data decrypted, and all the hashed data is a read only, preventing accidental changes to this data.
- the comparison function is used to compare the new counter click number (determined by the position in the hash table that matches, for example) with the last known counter click number. Decisions are optionally made according to the result of this function. Limited External Communications
- the server can send only two messages to the outside world: 'Card Valid' or 'Card Invalid'.
- This feature potentially prevents hackers from knowing why the card was not validated by the server, information that is often important for improving attacks on the server, h intra-network, secure communications with a card issuer or trusted third party server, the server optionally provides additional information as to why a particular card was not authenticated.
- the card when it is retried, it may pass the authentication, for example by showing that the supposed card holder has at least two one time correct (and optionally consecutive) codes.
- the system will enable administration of various operations, which may be useful when issuing cards, for example described below.
- a Card issuance process includes, in addition to the delivery of the cards to the users, one or more of the following operations: i. Addition of the card details to the database (e.g., basic record and/or hash list) ii. Association of the cardholder User ID and the Card 3D (optionally performed during personalization) iii. Activating the card's functionality. This may involve sending an adequate command to the server (e.g., in case the default is off). Alternatively, automatic activation may be performed, for example if two consecutive correct hash values are provided. Card Revocation and Un-revocation
- a Web based management interface which, after proper login, enables the operator/user to revoke cards based on the card ID.
- a Protocol based management interface enabling a computer to automatically revoke cards using different protocols, as defined and agreed with a vendor and/or a user Card Expiration
- expired cards assuming that new ones have been issued, will go through the revocation process, while in parallel, a new link will be created between the User ID and the new card.
- the record of the cards and the hash list are optionally backed up (e.g., in case the backups are not in the same place).
- no backing up is performed, as the hash list is generally static.
- Manufacturing is typically the first process in the card life span.
- the card is assembled in one of the proprietary manufacturing lines, located within a Visa-certified facility.
- a circuitry module is programmed with the manufacturer-Data, to be used later as the manufacturer-ID and Encrypted Data.
- the circuitry then goes through lamination and graphics, for example, cold lamination or hot lamination.
- the magnetic stripe (and/or Smart card module) is added, and the card is ready for personalization.
- the card may be personalized and/or various hash codes generated, prior to lamination. Authentication scheme:
- a counter is embedded within the Self-Powered Card (SPC) and is used as a basis for generating a random number.
- SPC Self-Powered Card
- the SPC also comprises a button, such that each time the button is pressed (i.e. the card is 'clicked'), the counter's value increases, and a new random number is generated and transmitted to the authentication server along with the rest of the data.
- a set of, for example, 10,000 (or any other number) of pseudo-random numbers is calculated, and the resulting numbers are hashed and stored in a database contained in the Authentication server, for example prior to the first card use.
- each unique hash number reflects a specific card 'click' rather than the actual counter's value. Therefore, consecutive hash numbers in the server reflect consecutive card 'clicks' (i.e. activations).
- the Authentication process itself is carried out according to the following method: the server receives a random code data from the SPC. At least a portion of this data is hashed, and the resulting hash value is searched for in the server's database. If there is a matching number in the database, the corresponding SPC's 'click' number is compared against the last known 'click' number; i.e. the last time this SPC was authenticated. If the new 'click' number is equal or less than the last known 'click' number, the SPC is considered to be invalid. In this case the authentication server may hold any confirmation of transactions using this electronic card, or take any other action as/if required.
- a reasonable number of 'clicks' per time period may be allowed. For example, an average user may use the card for purchasing commodities, show the card to his friends, and click on the button unintentionally. For example, a card may be allowed no more than 200 clicks per day. Hence, by keeping track of the click number and/or its history, unreasonable increments that may be an indication of a problematic SPC, can be detected or identified as artifacts. For example, a SPC user clicks bis card, and the Authentication server interprets the received data as 'click number 12'. If, however, at the same day the server receives another data but interprets it as 'click number 220', the Authentication server 'remembers' this click number (i.e.
- the card and server uses a different set of hash numbers for each day.
- a set of random numbers is generated, hashed and stored both in the card and in the Authentication server.
- no trace of the way by which this set of numbers is generated exists anywhere in the system after completing the numbers generation process.
- the set may be generated by skipping some numbers in a series, for example, every other number, or using a random jump.
- a pointer draws the next random number from the table, which is transmitted to the Authentication server.
- the server searches for a matching hash number in its own table, in order to find its corresponding click's number, after which it takes whatever required action, for example, using the same way as described in the first Authentication scheme.
- the card ID number in the main table is used to reduce the searching time in the hash table.
- a reduction in search time is provided by removing used, old, and/or 'wasted', hash values from the hash table, a wasted hash number is a hash number that relates to (or is a representative of) false clicks; for example, whenever a card is clicked without its transmission being received at the Authentication server (e.g. accidental clicks).
- One possible purpose of the security is to allow the owner of a device to carry out transactions in a secure manner, e.g., to ensure that the owner, and only the owner, will issue a transaction.
- achieving this object is provided by one or more of:
- the authentication scheme described herein allows preventing a replay attack.
- replay attack is not the only security consideration.
- one or both of the following issues is dealt with in accordance with an exemplary embodiment of the invention:
- the device/card is used in Internet transactions.
- a hacker may be able to 'get in the middle' between a legitimate user and a merchant, thus becoming an intermediate, or by pretending to be a real merchant and receive payment without providing goods.
- the hacker may, for example, send the user a message, pretending to be a genuine merchant, urging/tempting the user to reply.
- a legitimate user would not be able to tell whether he responds to the genuine merchant or to the hacker, and the hacker may take advantage of that fact by intercepting and abusively exploiting the data exchanged between the user and the genuine merchant.
- a special means is used in conjunction with an ActiveX control.
- the ActiveX control is a generic software element embedded in most of today's browsers. Whenever an Internet user enters a web site for the first time, the home page may prompt the user a request to download an ActiveX file, after which it remains in the user's PC. This file may at least contain parameters regarding the particular web page. If the user enters another web page, the user does not have to load the Active X again, and the already existing ActiveX dynamically changes its attributes to comply with the new web page.
- a merchant must acquire at least one of two certificates in order to allow him to securely interact with other parties by using the Internet.
- These certificates may be issued, for example, by a Certification Authority (CA) or by the ASP itself.
- the first certificate is referred to as the 'client certificate'.
- This certificate is used by the Authentication Service Provider (ASP) to verify the merchant.
- the second certificate is referred to as the 'server certificate', and it is used to verify a legitimate Internet user.
- the card is activated so that a data stream is transmitted from the card and received at the user's PC.
- the ActiveX Assuming that the ActiveX is operable, it receives the transmission and modifies it according to the following process, at the user computer and/or at a merchant computer:
- the ActiveX optionally adds the merchant's digital signature (i.e. the merchant 'server certificate') to the received data. This operation does not alter the original data received from the card;
- the ActiveX optionally, alternatively or additionally affiliates the specific web page parameters into the above signed data
- the ActiveX optionally, alternatively or additionally encrypts the resulting data by using the merchant's public key; and 4. the encrypted data is then forwarded from the merchant to the ASP.
- the ASP decrypts the data with its own private key, and the signed (by the merchant) data is extracted.
- the communication channel between the merchant and the ASP is secured, since it is carried out by using the SSL protocol and PKI technique.
- the ASP site i.e. authentication server
- enhanced security may result.
- the data, which is transmitted from the card, is secured since the data from a legitimate user bears the ASP imprint, as is carried out by the ActiveX in the user's PC.
- a hacker may intercept a data sent from a legitimate user. However, the hacker cannot sign the intercepted data with the proper signature. Therefore, whenever the ASP receives a data transmission from a hacker, this data is most likely to have a false signature, and therefore is ignored.
- a special attribute is added to the ActiveX in such a way, that whenever a user makes an attempt to load an ActiveX control, the ActiveX control searches, while on runtime, for the special attribute. If such an attribute is not found, the ActiveX control will turn off automatically, otherwise the ActiveX control is ready to analyze incoming signals and take further actions as required.
- the special attribute may be given by the Authentication Service Provider (ASP) to each authorized merchant.
- each merchant assigns a special number to each user on a session basis; namely whenever a cardholder enters the merchant's web page, the merchant assigns the card user a random 'one-time' number.
- the ActiveX control is activated and the special number is added to the card's data and launched to the merchant's web server, where it is compared with the original number sent by the merchant. If several users enter the same merchant's web page essentially at the same time, each one of them is given a different number, and if a user exits and reenters the web page, he is given a number that differs from the previous number he had. Sending one-time numbers, and receiving them as a feedback, may ensure to the merchant that the user is really who he says he is.
- the card may be signed by the ActiveX control using the merchants code and/or using the card.
- one or more of the following databases are provided for authentication, for example, at the server:
- PUBLIC CARD ID - this optional filed stores a card's ID (or alternatively a registration number) that is received from the card un-encrypted. It should be noted that there may be a situation, where the number of issued cards is relatively large, in which case two cards may transmit exactly the same transmission. However, it is expected that the card IDs will remain unique. Additionally or alternatively, this ID number may be used to n ⁇ nirnize the time required to find a hash code/number in this table.
- COUNTER VALUE this optional field holds the expected future counter click's number of a specific card, in order to allow comparing between two consecutive data received from the card.
- CARD_IDX TABLE - this optional table has one or more rows for each card.
- the main fields of the table are:
- this optional field contains a user JD, such as a credit card number.
- 3.3 Private Identification Number (PIN) VALUE this optional field appears in clear text or in hashed form. This number is not necessarily included in the card and therefore may have no role in the above Authentication procedure. This number is similar to a hardware/device serial number.
- 3.4 User Defined Fields (UDF) these optional fields (for example 10 fields but other numbers are possible too) are reserved for each card user/issuer, which may decide to fill them with various data, such as card's holder bank account number, address, telephone number, allowed credit, etc. Each field may contain, for example a maximum of 64 characters.
- this field contains the results of the Authentication attempts.
- MANAGEMENT LOG TABLE this optional table contains information about card management operations performed via Web-site management tools. Some possible fields for this table are: 5.1 3D - optional, number identifying the log entry.
- a card issuer can not be sure that the transaction code given by the merchant and the authenticated card relate to each other. Since a web site is involved, whether the merchant's or the card issuer's, the problem can is optionally solved by using a proper ActiveX file, which may include various parameters relating to the merchant and/or to the transaction and/or the user/buyer, such as PC's 3P address, timestamp, amount of transaction, URL and/or signature.
- a same device/card may be used in various applications, by using the same encrypted data generated by the card.
- the right application is selected according to the hash function applied by the corresponding Authentication server. For example, lets assume that there is a 2- application card, whenever this card transmits its data to a specific Authentication server, this server applies its unique hash function to Authentication the card. Should the user transmit his card data to the second Authentication server, another hash function is applied, to generate a different hash number.
- the differing hash functions and/or other associated information may be added, for example, by the vendor or by a subsidiary authenticator which may use the ASP for providing some authentication services.
- Fig. 1 schematically illustrates a process for authenticating a SPC, according to one embodiment of the invention.
- a card 100 transmits a counter value 10 and a card-ID 20 over a connection 30, to an authentication server 200, where the card 3D is used to lookup in a table 40.
- connection 30 is encoded, for example using the cards one time code.
- Fig. 2 schematically illustrates an authentication scheme of a device, according to another preferred embodiment of the invention.
- a further security is provided by employing a security 3D (e.g., a key) 50, at the card, for example one which is a public key of authentication server 200.
- the data may be hashed, as described above and used to lookup in a hash table 40, for example according to card-ID.
- Fig. 3 schematically illustrates an authentication situation, wherein an authentication service provider 35 (ASP) authenticates a user 300:31 (i.e. potential buyer) before carrying out an Internet transaction with a merchant 36, in accordance with an exemplary embodiment of the invention.
- ASP authentication service provider 35
- the user 300 enters the merchant's web page 36. Entering the merchant's web page 36 for the first time prompts the user to download a copy of the generic ActiveX control 37A to the user's PC 37B.
- the cardholder wishes to carry out a transaction, he presses his card 31, which in turn launches the card's encoded details to the PC 33 by transmission signal 32.
- the ActiveX control on the PC 33 has the capability to identify the transmitted signal 32; e.g.
- the ActiveX control optionally digitally signs the card's data with the merchant web server's certificate.
- the ActiveX control optionally adds, to the signed data, the specific web page parameters, and optionally encrypts the resulting data by using the ASP's public key (or a public key relating to the merchant, for further verification by the ASP).
- the encrypted signal 32' is then sent to the merchant's web server 36.
- the merchant optionally adds his public key 36A and forwards the data to the ASP 35 optionally using the Secure Sockets Layer (SSL) protocol, which is a protocol for managing the security of a message transmission on the Internet.
- SSL Secure Sockets Layer
- the ASP owns the Authentication Server, which optionally performs one or both of two principal tasks, one of which is to verify the merchant, and the second is to authenticate the card itself. Verifying the merchant and the user is simultaneously carried out by the ASP by comparing the received merchants server's certificate to the ASP's list. If the ASP finds it in his list (or using a hash thereof compares it to a suitable list), it indicates that the merchant is really who he says he is (e.g., if the ASP himself gave the certificate to the merchant). On the other hand, since the merchant certificate was added to the user's data in the user's PC, it also indicates that the user is really who he says he his, and the card authentication may be carried out.
- the ActiveX 37A has an important role in the above-mentioned process, since it collects details from one or both of the merchant web page 36 and the user's PC (33), and digitally signs it with a server 30 certificate 36B of the merchant (which was provided to him by the ASP).
- the ActiveX also encrypts this data by using the public key of the ASP.
- Fig. 4A illustrates an Authentication scheme, in accordance with an exemplary embodiment of the invention.
- a pseudo-random numbers generator RNG
- the 2-key T-DES is used to generate a random number, from the latter two types of data, each time the card is activated (i.e. 'clicked').
- the 2-key T-DES is optionally permanently stored inside the card.
- Another mechanism is optionally stored inside the card, of which purpose is to change the counter value 41 each time the card is clicked.
- the public card JD 44 Since the public card JD 44 typically does not play any role in the Authentication process, it is added to the transmitted signal 46 after the generation of the random data X t (45). It should be noted that the 2-key T-DES is only an option to generate the random numbers in the card, and other pseudo-random generators may be used instead. 5 Since each transmission 46 from the card yields a progressively higher counter value, a new data content 45 is generated, which is a reflection of the secret card ID 42 and the counter's value 41. Knowing the rule by which the counter's value changes, an arbitrary- sized set of future numbers can be anticipated. In an exemplary embodiment of the invention, the card is expected to withstand at least 10,000 squeezes/presses, a set of 10,000 random
- 10 numbers is hashed and stored in a database 50 or 40 (which is optionally contained in the Authentication server).
- the card's counter value increases according to the predefined rule.
- the increased counter's value 41 and the card's secret 3D number 42 are used to generate a random number by applying the card's internal two predefined keys 43
- the random number 45 is transmitted, along with the public card ID 44, to the Authentication server through a receiving means; e.g. a PC.
- the Authentication server upon receiving the transmitted data 46 from the card, extracts the public card ID (47), and generates from the remaining data (J t ) a hash number 48 (Y t ), and the hashed number is searched for in the hash database/table column 49
- the rows in the hash table are arranged according to the original counter values; namely the first row of the table contains the hashed number 50: yl which represents the initial counter's value, the second row represents the second counter's value and so on.
- the Authentication procedure is based on the counter click number (see table: 50). If the card is clicked for the first time, its counter's value is expected to be the initial random value as was set during the manufacturing process of the card.
- the Authentication server Upon receiving the transmitted data 46 from the card, the Authentication server applies the hash function 48 on this data to yield the first hash number yl (49 A). Since yl represents the original first
- the server When the Authentication server receives the second transmission 46 from the card, the server hashes 48 the data X t ('i' denotes the card's click number) to yield another hash value 48: y t , after which it is searched for in table 50. It is taken into account that a cardholder might mistakenly squeeze his card several times between each two transactions, but nevertheless, there is still a logical hmit to such accidental squeezes. A decision-making algorithm, relating to this logical limit, may take into account different considerations. Therefore, if the second received data yields a hash number like y8, which represents counter click number 8, it might be considered a viable transmission of a legitimate card. If, however, the second received data yields a hash value like yl55 (49B), the card, from which this data was transmitted, may be considered illegitimate, or other decisions may be taken.
- the Authentication procedure optionally relates, therefore, to the difference between two consecutive card transmissions as received in the Authentication server and represented by the counter click number.
- the same Authentication procedure repeats itself every time the Authentication server receives a transmitted data.
- Each received data is hashed, searched for in the hash table and the corresponding counter click number is compared against the last known counter click number.
- Fig. 4B illustrates a second, alternative, possible Authentication scheme.
- a set 52 of pseudo-random numbers is generated, for example, by using a key 51 and hashed.
- the hash numbers are stored both in the card and in the server 50. Alternatively, original numbers may be stored in one or both locations.
- the random numbers generator/key 51 may be any generator known in the art. After completing the process of generating, hashing and storing the hash numbers, the key is discarded.
- pointer 49C points to the (new) consecutive hash number, which is to be transmitted from the card, hi the server, each received hash number (yl, y2, etc.) is searched for in table 50, and if it is found, the corresponding counter click number is determined.
- the Authentication process is continued the same way as in the first scheme; namely by comparing the counter clicks of consecutive receptions from a card.
- information is transmitted from the authentication/identification device over the telephony system.
- the telephony system is typically designed to deliver audio signals, and thus high frequencies are filtered, and therefore transmission of ultrasonic signals is usually acceptable over the regular telephony system.
- a sonic signal is utilized in telephony implementations.
- a same card may be used to transmit simultaneously both sonic and ultrasonic signals.
- the information is transmitted utilizing Frequency Shift Keying of sonic signals (herein after will be refened to as multitone FSK).
- n different data symbols are represented by n different frequencies (i.e., each symbol is assigned a predefined frequency), so that the decoding of such a transmission is carried out by modulating data symbols utilizing transmission of signals of predefined frequencies.
- four frequencies F0, FI, F2, and F3, are utilized for the multitone FSK signal.
- Fig. 5 A schematically illustrates the structure of the multitone FSK signal according to an exemplary embodiment of the invention.
- the first part of the detection preamble comprise a signal of frequency F0 over an interval of nO*Tb seconds
- the second part of the detection preamble comprise a signal of frequency FI over an interval of nl*Tb, where nO and nl are integers and Tb is the duration in seconds of a symbol, called the symbol interval.
- the frequency sequence utilized for detection may be comprised from any number of predefined frequencies, for example, from the set of frequencies utilized for FSK encoding.
- the detection preamble is optionally followed by a synchronization sequence and then by the encoded data.
- Other orders and/or signal parts may be provided, for example, an error correction section.
- the Hubert transform X " F ⁇ H ⁇ ) X ⁇ » of the signal x " , received in 610, is utilized in 600 to obtain the complex analytical representation n J n of the received signal.
- this form of correlation detection is less vulnerable to the delay incurred between the correlated windows ⁇ , or the duration of the correlation a-b, while allowing other signals to be erroneously detected.
- the tradeoff may allow a less computationally intensive detection method to be used, so that the PC may be used as a detector, rather than a dedicated DSP.
- Such a tradeoff may also be desirable in other problematic situations, for example, detecting RF signals transmitted by such a handheld card and detecting ultrasonic signals transmitted by the card and received by a non-dedicated microphone.
- the detection of a transmitted signal is performed, for example based on correlation tests as illustrated in Fig. 5B.
- the detection is, for example, based on the correlation of 601 obtained by the correlators 501 and 511.
- the correlation in 601 is performed on the received signal and a delayed portion of the received signal for the purpose of detecting the sinusoids F0 and FI in the detection preamble of the transmission. Alternatively, other detection methods are used.
- the correlator 501 correlates the samples received in the interval t — ( vn o T b J )/2 - ⁇ ⁇ ⁇ - ⁇ t (Bank 0) with the samples received in the interval
- the correlator 511 correlates the samples received in the interval t - (n 0 T b ) ⁇ (n l T b )/2 ⁇ ⁇ ⁇ t - (n Q T b ) ⁇ ⁇ with ⁇ samples received in the interval t - (n 0 + n T b ⁇ T ⁇ t - (n 0 T b ) - (n ⁇ )/ 2 ⁇ a ⁇ ⁇ ⁇ he chofce of symbol mt ⁇ rval T b used m calculating the above correlations is optionally derived from considerations regarding the hardware that generates the transmission waveform. In accordance with the hardware, minimum and maximum symbol durations T * are optionally identified, from which the correlator will use the minimum. In this way, the correlators may be better guaranteed to exclusively identify their intended frequencies.
- the correlators results are validated, this is optionally performed utilizing slicers 502 and 512.
- the slicers 502 and 512 optionally issue a TRUE indication whenever the correlation result is greater that a predetermined threshold, ⁇ ° and ⁇ respectively. If the signal received is of the form depicted in Fig. 5 A, than the output of correlators 501 and 511 will indicate a maximal correlation, and slicers 502 and 512 will issue a true indication, which will result in issuing a TRUE indication on 516 (i.e., signal detection).
- the threshold is detennined based on the noise level, for example, by analyzing the amplitude level in a known part of the signal for example, the preamble.
- an estimate of the frequency ⁇ may be found.
- the estimate is compared with a bounds on what frequency are allowed, which bound is optionally defined based on the inherent inaccuracies in the hardware that generates the signal and/or well as the minimum SNR allowed. Therefore, a signal may be accepted based on whether it has sufficient correlation energy (from the correlators 501 and 511) and/or whether it has an acceptable frequency.
- the correlation passes the validation test in 602, in 603, another test is optionally performed to determine whether the frequencies and the SNR (Signal to Noise Ratio) are within an acceptable tolerance for detection.
- the frequencies are optionally estimated using an approach described in "A Fast and Accurate Single Frequency Estimator.” by Kay, SM, IEEE Transactions on Acoustics, Speech, and Signal Processing, Vol 37, No 12, Dec 1989, where the data used in the Kay analysis is the same as that already in the delay lines for using the correlator detector described previously, whereas the SNR is determined by using a window of delayed samples to estimate the frequency-dependent noise power.
- detection is optionally determined using statistical hypothesis testing between the energy at the output of the received correlators and the energy at the same frequency, as estimated from the noise window.
- the threshold is optionally calculated using the Neyman-Pearson criterion. (This approach is described in US patent application No.
- the resampled signal is then optionally utilized in 607 to calculate the signal's timing from a known preamble, (This approach is described in US patent application No. US 09/570,399 of the same applicant), which is utilized in 608 to further determine if the signal is valid. If it is determined that the signal is invalid, the process starts again from 610 (as a new sample is retrieved). If a valid indication is obtained in 608, detection is completed and the decoding operations are performed in 609. Other detection schemes, for example with fewer levels or with a greater number of levels and/or with additional and/or alternative verification criteria, may be used.
- Fig. 7 schematically illustrates the decoding operation, according to a preferred embodiment of the invention.
- the resampled signai, obtained in 606, is correlated in correlators 701, 702, and 703.
- the number of correlators is optionally the same as the number of different frequencies (symbols) utilized for the FSK transmission. Alternatively, a single correlator may be reused.
- the resampled signal 700 is correlated with the estimated frequencies for each signal °' 1 ''"' " , which were estimated, for example, from the Kay algorithm referenced above.
- the slicers 711, 712, and 713 test the output of each correlator 701, 702, and 703, respectively, to determine if a maximum correlation is obtained. Whenever the output of a correlator 701, 702 or 703, exceed the threshold of the corresponding sheer, a match indication is issued on the output of the respective sheer. This indication is actually a decoded symbol.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP02707082.0A EP1381985A4 (en) | 2001-03-22 | 2002-03-21 | A method and system for remotely authenticating identification devices |
AU2002241234A AU2002241234A1 (en) | 2001-03-22 | 2002-03-21 | A method and system for remotely authenticating identification devices |
US10/668,109 US9219708B2 (en) | 2001-03-22 | 2003-09-22 | Method and system for remotely authenticating identification devices |
Applications Claiming Priority (10)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US27806501P | 2001-03-22 | 2001-03-22 | |
US27799601P | 2001-03-22 | 2001-03-22 | |
US27801001P | 2001-03-22 | 2001-03-22 | |
US60/278,065 | 2001-03-22 | ||
US60/277,996 | 2001-03-22 | ||
US60/278,010 | 2001-03-22 | ||
US09/853,017 US7280970B2 (en) | 1999-10-04 | 2001-05-10 | Sonic/ultrasonic authentication device |
US09/853,017 | 2001-05-10 | ||
PCT/IL2001/000758 WO2002014974A2 (en) | 2000-08-14 | 2001-08-14 | Multi-server authentication |
ILPCT/IL01/00758 | 2001-08-14 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IL2001/000758 Continuation-In-Part WO2002014974A2 (en) | 1999-10-04 | 2001-08-14 | Multi-server authentication |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/668,109 Continuation US9219708B2 (en) | 2001-03-22 | 2003-09-22 | Method and system for remotely authenticating identification devices |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2002078199A2 true WO2002078199A2 (en) | 2002-10-03 |
WO2002078199A3 WO2002078199A3 (en) | 2003-02-27 |
Family
ID=27517574
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IL2002/000235 WO2002076717A2 (en) | 2001-03-22 | 2002-03-21 | Manufacture of self-powered identification devices |
PCT/IL2002/000236 WO2002078199A2 (en) | 2001-03-22 | 2002-03-21 | A method and system for remotely authenticating identification devices |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IL2002/000235 WO2002076717A2 (en) | 2001-03-22 | 2002-03-21 | Manufacture of self-powered identification devices |
Country Status (3)
Country | Link |
---|---|
EP (2) | EP1407418A4 (en) |
AU (1) | AU2002249532A1 (en) |
WO (2) | WO2002076717A2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004088917A1 (en) | 2003-04-01 | 2004-10-14 | Entropic Technologies Pty Ltd | A system for secure communication |
EP1811452A1 (en) * | 2004-11-08 | 2007-07-25 | Sony Corporation | Information processing system and information processing device |
FR2898424A1 (en) * | 2006-03-10 | 2007-09-14 | Gisele Ep Pardo Simonpietri | Transaction e.g. purchasing of goods, securing system for electronic commerce, has customer identification device with command permitting access to control program to automatically connect device to operation validation digital intermediary |
US9607475B2 (en) | 1998-09-16 | 2017-03-28 | Dialware Inc | Interactive toys |
CN111630812A (en) * | 2018-01-15 | 2020-09-04 | 三菱日立电力系统株式会社 | Remote service system |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6607136B1 (en) | 1998-09-16 | 2003-08-19 | Beepcard Inc. | Physical presence digital authentication system |
WO2000021020A2 (en) | 1998-10-02 | 2000-04-13 | Comsense Technologies, Ltd. | Card for interaction with a computer |
US8019609B2 (en) | 1999-10-04 | 2011-09-13 | Dialware Inc. | Sonic/ultrasonic authentication method |
US9219708B2 (en) | 2001-03-22 | 2015-12-22 | DialwareInc. | Method and system for remotely authenticating identification devices |
US7237724B2 (en) | 2005-04-06 | 2007-07-03 | Robert Singleton | Smart card and method for manufacturing a smart card |
US7607249B2 (en) | 2005-07-15 | 2009-10-27 | Innovatier Inc. | RFID bracelet and method for manufacturing a RFID bracelet |
CA2648900A1 (en) | 2006-04-10 | 2007-11-08 | Innovatier, Inc. | An electronic inlay module for electronic cards and tags |
US20070290048A1 (en) | 2006-06-20 | 2007-12-20 | Innovatier, Inc. | Embedded electronic device and method for manufacturing an embedded electronic device |
CN101794479A (en) * | 2010-04-08 | 2010-08-04 | 中国工商银行股份有限公司 | Bank card making system and card exchanging system |
WO2012099863A1 (en) * | 2011-01-18 | 2012-07-26 | Robert Singleton | A method for attaching an electronic assembly to a bottom overlay in the manufacture of an electronic device |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5903721A (en) * | 1997-03-13 | 1999-05-11 | cha|Technologies Services, Inc. | Method and system for secure online transaction processing |
US6332163B1 (en) * | 1999-09-01 | 2001-12-18 | Accenture, Llp | Method for providing communication services over a computer network system |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5955961A (en) * | 1991-12-09 | 1999-09-21 | Wallerstein; Robert S. | Programmable transaction card |
US5817207A (en) * | 1995-10-17 | 1998-10-06 | Leighton; Keith R. | Radio frequency identification card and hot lamination process for the manufacture of radio frequency identification cards |
US6036099A (en) * | 1995-10-17 | 2000-03-14 | Leighton; Keith | Hot lamination process for the manufacture of a combination contact/contactless smart card and product resulting therefrom |
US5786988A (en) * | 1996-07-02 | 1998-07-28 | Sandisk Corporation | Integrated circuit chips made bendable by forming indentations in their back surfaces flexible packages thereof and methods of manufacture |
IL127569A0 (en) * | 1998-09-16 | 1999-10-28 | Comsense Technologies Ltd | Interactive toys |
WO2000021020A2 (en) * | 1998-10-02 | 2000-04-13 | Comsense Technologies, Ltd. | Card for interaction with a computer |
US6257486B1 (en) * | 1998-11-23 | 2001-07-10 | Cardis Research & Development Ltd. | Smart card pin system, card, and reader |
FR2790849B1 (en) * | 1999-03-12 | 2001-04-27 | Gemplus Card Int | MANUFACTURING METHOD FOR CONTACTLESS CARD TYPE ELECTRONIC DEVICE |
EP1065634A1 (en) * | 1999-07-02 | 2001-01-03 | Mic Systems | System and method for performing secure electronic transactions over an open communication network |
US7437560B1 (en) * | 1999-07-23 | 2008-10-14 | Cubic Corporation | Method and apparatus for establishing a secure smart card communication link through a communication network |
-
2002
- 2002-03-21 EP EP02718485A patent/EP1407418A4/en not_active Ceased
- 2002-03-21 EP EP02707082.0A patent/EP1381985A4/en not_active Ceased
- 2002-03-21 AU AU2002249532A patent/AU2002249532A1/en not_active Abandoned
- 2002-03-21 WO PCT/IL2002/000235 patent/WO2002076717A2/en not_active Application Discontinuation
- 2002-03-21 WO PCT/IL2002/000236 patent/WO2002078199A2/en not_active Application Discontinuation
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5903721A (en) * | 1997-03-13 | 1999-05-11 | cha|Technologies Services, Inc. | Method and system for secure online transaction processing |
US6332163B1 (en) * | 1999-09-01 | 2001-12-18 | Accenture, Llp | Method for providing communication services over a computer network system |
Non-Patent Citations (1)
Title |
---|
See also references of EP1381985A2 * |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9607475B2 (en) | 1998-09-16 | 2017-03-28 | Dialware Inc | Interactive toys |
US9830778B2 (en) | 1998-09-16 | 2017-11-28 | Dialware Communications, Llc | Interactive toys |
WO2004088917A1 (en) | 2003-04-01 | 2004-10-14 | Entropic Technologies Pty Ltd | A system for secure communication |
EP1620970A1 (en) * | 2003-04-01 | 2006-02-01 | Entropic Technologies Pty Ltd | A system for secure communication |
EP1620970A4 (en) * | 2003-04-01 | 2010-12-22 | Entropic Technologies Pty Ltd | A system for secure communication |
EP1811452A1 (en) * | 2004-11-08 | 2007-07-25 | Sony Corporation | Information processing system and information processing device |
EP1811452B1 (en) * | 2004-11-08 | 2010-04-21 | Sony Corporation | Information processing system and information processing device |
US7994915B2 (en) | 2004-11-08 | 2011-08-09 | Sony Corporation | Information processing system and information processing apparatus |
FR2898424A1 (en) * | 2006-03-10 | 2007-09-14 | Gisele Ep Pardo Simonpietri | Transaction e.g. purchasing of goods, securing system for electronic commerce, has customer identification device with command permitting access to control program to automatically connect device to operation validation digital intermediary |
CN111630812A (en) * | 2018-01-15 | 2020-09-04 | 三菱日立电力系统株式会社 | Remote service system |
CN111630812B (en) * | 2018-01-15 | 2023-03-28 | 三菱重工业株式会社 | Remote service system |
Also Published As
Publication number | Publication date |
---|---|
EP1407418A4 (en) | 2010-06-23 |
WO2002076717A3 (en) | 2004-01-15 |
EP1381985A2 (en) | 2004-01-21 |
WO2002078199A3 (en) | 2003-02-27 |
WO2002076717A2 (en) | 2002-10-03 |
EP1381985A4 (en) | 2013-06-26 |
EP1407418A2 (en) | 2004-04-14 |
AU2002249532A1 (en) | 2002-10-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9219708B2 (en) | Method and system for remotely authenticating identification devices | |
US8826019B2 (en) | Centralized authentication system with safe private data storage and method | |
US8713661B2 (en) | Authentication service | |
US6836765B1 (en) | System and method for secure and address verifiable electronic commerce transactions | |
US8752153B2 (en) | Accessing data based on authenticated user, provider and system | |
US8751829B2 (en) | Dispersed secure data storage and retrieval | |
US7412420B2 (en) | Systems and methods for enrolling a token in an online authentication program | |
AU2010215040B2 (en) | System and methods for online authentication | |
AU2009238204B2 (en) | Authenticating electronic financial transactions | |
US8839391B2 (en) | Single token authentication | |
US20060123465A1 (en) | Method and system of authentication on an open network | |
US20080216172A1 (en) | Systems, methods, and apparatus for secure transactions in trusted systems | |
WO2008063877A2 (en) | Card authentication system | |
US20040059686A1 (en) | On-line cryptographically based payment authorization method and apparatus | |
WO2002078199A2 (en) | A method and system for remotely authenticating identification devices | |
AU2015202661B2 (en) | System and methods for online authentication | |
AU2009202963A1 (en) | Token for use in online electronic transactions | |
Nali et al. | CROO: A Generic Architecture and Protocol to Detect Identity Fraud | |
Nali et al. | CROO: A Universal Infrastructure and Protocol to Detect Identity Fraud (Extended Version) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
AK | Designated states |
Kind code of ref document: A3 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
WWE | Wipo information: entry into national phase |
Ref document number: 10668109 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2002707082 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2002707082 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
NENP | Non-entry into the national phase in: |
Ref country code: JP |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |