WO2002014974A2 - Authentification par serveurs multiples - Google Patents

Authentification par serveurs multiples Download PDF

Info

Publication number
WO2002014974A2
WO2002014974A2 PCT/IL2001/000758 IL0100758W WO0214974A2 WO 2002014974 A2 WO2002014974 A2 WO 2002014974A2 IL 0100758 W IL0100758 W IL 0100758W WO 0214974 A2 WO0214974 A2 WO 0214974A2
Authority
WO
WIPO (PCT)
Prior art keywords
card
authentication
information
issuer
server
Prior art date
Application number
PCT/IL2001/000758
Other languages
English (en)
Other versions
WO2002014974A3 (fr
Inventor
Ram Anati
Danny Atsmon
Alan Sege
Original Assignee
Comsense Technologies, Ltd.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from IL13785400A external-priority patent/IL137854A0/xx
Priority to US09/853,017 priority Critical patent/US7280970B2/en
Application filed by Comsense Technologies, Ltd. filed Critical Comsense Technologies, Ltd.
Priority to AU2001282453A priority patent/AU2001282453A1/en
Publication of WO2002014974A2 publication Critical patent/WO2002014974A2/fr
Priority to PCT/IL2002/000235 priority patent/WO2002076717A2/fr
Priority to EP02707082.0A priority patent/EP1381985A4/fr
Priority to PCT/IL2002/000236 priority patent/WO2002078199A2/fr
Priority to AU2002249532A priority patent/AU2002249532A1/en
Priority to AU2002241234A priority patent/AU2002241234A1/en
Priority to EP02718485A priority patent/EP1407418A4/fr
Publication of WO2002014974A3 publication Critical patent/WO2002014974A3/fr
Priority to US10/668,109 priority patent/US9219708B2/en

Links

Classifications

    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • 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
    • 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/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
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H04L63/0218—Distributed architectures, e.g. distributed firewalls
    • 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
    • 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

Definitions

  • the present invention relates to authentication of cards for on-line transactions.
  • BACKGROUND OF THE INVENTION Cards in the bank-card form factor, are ubiquitous, and people everywhere use them for transactions and identification. Previously, people could only use those cards at dedicated machines such as ATMs and to make purchases at those stores that accept their cards. In a world where every Internet device is a point of sale, that is not enough.
  • transaction cards that generate a one-time code per transaction are known, for example, smart cards.
  • the code for a transaction is verified by a central location, which issues the cards.
  • An aspect of some embodiments of the invention relates to distributing the authentication of a transaction performed using a transactional card.
  • an authentication of a code generated by the card is performed by one of several distributed authentication servers, for example based on availability or on affiliation of the authentication server with a transaction manager.
  • An aspect of some embodiments of the invention relates to performing at least some of the authentication of a transactional card using an authentication server that is not affiliated with a card issuer.
  • the authentication of a card is by a card producer (which is not a card issuer) or by a third party authenticator.
  • a single card may be "issued" by several card issuers, each of which may selectively authenticate a transaction.
  • An aspect of some embodiments of the invention relates to a database for a distributed authentication server, in which only hash functions of authentication data is stored. Thus, if such a server is broken into, there is no data available to be stolen.
  • each such server may add its own level(s) of authentication, for example, passwords.
  • the contact with the card holder is via a WWW page into which the card holder enters the transactional information.
  • a single software unit, for example an ActiveX element is used for a plurality of different authentication servers.
  • An aspect of some embodiments of the invention relates to a transactional card that can emulate a plurality of different cards provided by different card issuers.
  • the card generates a single code that is selectively authenticated by only one card-issuer associated authentication server.
  • the card can selectively generate information for a plurality of card issuers.
  • the card real- estate reflects the current programming/emulation ability of a card.
  • An aspect of some embodiments of the invention relates to dividing up authentication functions between a plurality of locations and computers, including one or more of:
  • safety rules e.g., is card being used in an abnormal manner
  • even a single authentication step is performed by two different computers, separately, or together. Alternatively or additionally, for some transactions, not all authentication levels are performed. Optionally, the number of partial authentications and/or their total sum is tracked.
  • FIG. 1 is a block diagram of an authentication configuration, in accordance with an exemplary embodiment of the invention
  • FIG. 2 is a schematic illustration of a transaction card, in accordance with an exemplary embodiment of the invention.
  • Fig. 3 is a schematic side illustration of a modular switch, in accordance with an exemplary embodiment of the invention.
  • Fig. 4 is an overview of an exemplary process of ComSense card authentication, in accordance with an embodiment of the present invention
  • Fig. 5 illustrates the process of key generation, management, and the creation of hash databases bearing a one-to-one relationship with the set of one-time codes that each card is capable of transmitting, in accordance with an embodiment of the present invention
  • Fig. 6 illustrates the interrelationships of the system components of the ComSense solution for Issuer, in accordance with an embodiment of the present invention
  • Fig. 7 is an illustration of the system data flow, in accordance with an embodiment of the present invention.
  • Fig. 8 is a schematic illustration of an exemplary system architecture, in accordance with an embodiment of the present invention. DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
  • Fig. 1 is a block diagram of an authentication configuration 100, in accordance with an exemplary embodiment of the invention.
  • a card 102 sends transaction information to a browser 104.
  • the transaction information is decoded by a receiver 108, which may or may not be part of the browser.
  • the receiver and the browser are on a same computer, however, this is not required.
  • a distribution center 110 receives the information from receiver 108 and sends the transactional information to an authorization server 112, which compares the transactional information against information stored in a local validation database 114. It is a particular feature of some embodiments of the invention that a plurality of possible authentication servers 112 and 112' are available.
  • Card 102 maybe any type of transactional card, for example an acoustic card that communicates with a computer via its microphone, such as described in PCT publications WO 00/21020 and WO 00/21203 and in US patent application filed May 12, 2000, attorney docket 20257-11, by applicants Alon Atsmon, et al., and entitled "Physical Presence digital Authentication System", the disclosures of which are incorporated herein by reference.
  • other transactional means are used, for example, cellular telephones, smart cards and devices using bluetooth communication, such as palm computers.
  • such electronic devices may function as card readers.
  • the transactional information may be electronic, for example, various forms of electronic cash.
  • the connection may be one directional (only card to computer) or two directional.
  • a transactional card may be operated over telephone lines or using dedicated software, for example.
  • the card generates a one time code, using a counter-based random number generation function.
  • card 102 generates a digital signature for a transaction content and/or time and/or vendor.
  • receiver 108 comprises an ActiveX type software module or a Java applet that forms part of a WWW page through which the transaction is being performed.
  • a single applet is used for a plurality of different pages and/or card issuers, for example being downloaded from a central source or being provided locally on the computer.
  • a stand alone acoustic recognition software may be used instead.
  • no distribution server 110 is provided, for example, receiver 108 sending the information directly to a predetermined authentication server (or only one provided, or only one being relevant) or distribution server 110 being integrated with receiver 108 and/or browser 104.
  • the determination which authentication server to send to is dependent on the contents of the WWW page, on the card ID or on other information entered at browser 104 (e.g., via an "other" input 106) and/or on the information transmitted by the card.
  • the transaction information from card 102 may include, for example, one or more of the card ID, a counter count, a code generated using the counter and/or information entered using the card.
  • a user may provide additional transactional information, for example, by entering it using other input 106 (e.g., a keyboard and/or a mouse) or the information may be acquired from the WWW page, for example an amount or a vendor identification. Possibly, such information is tagged in an HTML file used for displaying the page or transmitted when a submit button on the page is activated.
  • card 102 may act as a submit button. Additional transactional information may thus be added by one or more of card 102, other input 106, browser 104, receiver 108 and distribution center 110.
  • a plurality of authentication servers 112 maybe desirable for several reasons, for example, one or more of:
  • authentication server 112 validates the transactional information using validation database 114.
  • the validation is by comparing the transactional information to information in database 114.
  • database 114 a hash of the original information, rather than the information itself. Thus, if database 114 is hacked into, it cannot yield the authentication info ⁇ nation.
  • an MD5 type hash function is used.
  • a hash function is a function that maps original information into an indecipherable sequence of symbols. In some cases a real hash function is used, characterized in that no reverse hashing can be performed. Alternatively, a reversible hashing is used, for example, public key encryption. In these embodiments, a decryption key may be stored at database 114.
  • database 114 contains, for a plurality of cards, a plurality of codes matching a plurality of counter values and, optionally card IDs.
  • database 114, or an additional database may include other authentication information, such as a password entered using other input 106.
  • other input 106 comprises a biometrics input, such as a retina reader or a fingerprint detector.
  • database 114 is for time-stamped codes, the database may include a plurality of codes for the different times. In one example, a record is stored for each card at time steps of one minute. Different databases 114 may use the same hash or they may not. Thus a same card may be authenticated against different data in different authentication servers. Conversely, the choice of a hash function may determine which authentication server 112 can perform the authentication.
  • Hashing of the transactional information may be performed at one or more of: card 102, browser 104, receiver 108, distribution enter 110 and authentication server 112.
  • a check for the validity of the counter used to generate the transactional code is also performed, for example at authentication server 112 or at a central validation center 118.
  • a counter distributor 116 may distribute current and/or update values of counters (or corresponding data records) between the authentication servers, to keep them up to date.
  • the counter validation is only performed to see if the counter is within a small number of counts from a previously known value. If the counter is outside the range, a special request to counter distributor 116 may be performed.
  • counter values are pre-fetched to localities where activity of a particular card is detected, for use in expected further activations of the card.
  • Additional validation steps may be performed at one of the above validation and authentication servers or at a separate additional authentication server, for example at a separate password authenticator (not shown).
  • the above described authentications may be divided among the available authenticators in various ways, for example varying the location and/or level of authentication.
  • different levels of authentication are required for different activities, for example, low cost or security activities (e.g. viewing a WWW page) may only require presenting a valid card ID, while higher cost activities (e.g., modifying information) may require code validation, counter validation and/or entering a password.
  • low cost or security activities e.g. viewing a WWW page
  • higher cost activities e.g., modifying information
  • code validation e.g., counter validation and/or entering a password.
  • no counter validation is required Changing the home address, may require such validation.
  • connections from home require a weaker authentication than connections away from home, for example, an additional password or a less-likely to be overcome hash function.
  • the card includes the ability to selective advance the counter or not.
  • a counter validation may be based on a series of correct counters being presented by the card, indicating that it is the true card.
  • a time stamp is used, alternatively or additionally to using a counter.
  • a card 106 may include a clock.
  • the card may retrieve the clock, or other limited duration information, from browser 104, receiver 108, distributor 110 or authentication server 112.
  • the validity of a time stamped content may be checked, using a suitable entry in database 114.
  • database 114 includes entries corresponding to a small number of transaction amounts.
  • databases 114 are limited to represent only those cards that are currently (and/or expected to be) in the jurisdiction of authentication server 112. Thus, one card can only be authenticated by only one server, while another card can be authenticated by two servers.
  • a physical single card can be issued by a plurality of card issuers.
  • Various methods may be implemented to differentiate between the card issuer to be used for a particular transaction.
  • the transactional information for example entered (or pre-set) on a WWW page may determine the issuer.
  • a single physical card may transmit a different code to represent cards by different emulated card issuers.
  • a card transmits a series of different Ids for different issuers.
  • one of the elements along the line between browser 104 and authentication server 112 converts a card ID into a card issuer ID, for example using information provided by the user or by the card issuer.
  • a user may set rules for card issuer selection.
  • multiple activations of a card are used to represent different card issuers, for example, by receiving a number of consecutive codes by receiver 108.
  • the car may transmit different codes depending on a length or number of presses of a switch on the card.
  • the first card issuer to respond to an authentication request, or a card issuer that charges a lowest cost overhead is selected. The charge amount may be transmitted only after a card issuer is selected.
  • the authentication may be performed by a central server.
  • a single card ID is registered with one or more card issuers.
  • the card ID is linked to the card issuer ID, but is not registered. Registration allows the authentication server to recognize the card as belonging to an issuer.
  • hardware or software modification of the card enables such registration and/or otherwise controls the codes sent by the card and/or the type of distribution effected by distributor 110 and/or type of authentication by authentication server 112 and/or other authentication or validation servers.
  • a single physical card may be required to emulate a plurality of credit card issuers.
  • a potential property of such a card is that the card does not belong to a credit card company.
  • the utilization of real-estate on the card surface may be more flexible.
  • the card may not conform to all credit card design standards.
  • a card 102 can be programmed, for example acoustically (e.g., for an acoustic card) or via smart card contacts or RF radiation, to include the required emulation for the various card issuers.
  • Fig. 2 is a schematic illustration of a multiple endorsement transaction card 200, in accordance with an exemplary embodiment of the invention.
  • Card 200 comprises a body 202 having one or more standard card features, such as a number area 204.
  • card 200 includes a plurality of endorsement areas 206, 208, 210, 212 and 214; any number of such areas may be provided.
  • a suitable sticker may be provided, for example, by mail, to place in an endorsement area.
  • the endorsement areas are depressed, so the sticker does not affect the thickness profile of the card.
  • the width variations may be limited to areas where the card does not affect the expected card functionality (e.g., ATM machine).
  • a sticker may be removable or it may be designed to be damaged when removed. It should be noted that the card packaging can vary, for example, if the card is emulated by a cellular telephone or a smart card.
  • an endorsement area 210 includes two or more contacts 216, two or more or which are shorted by the back of the sticker (if placed correctly).
  • the shorting of the contacts may identify the endorsement on the face of the sticker and/or may determine hardware functionality and/or transmitted codes of card 200.
  • the shorting may be pattern-less, for example using a conductive adhesive on the back of the sticker.
  • the sticker may contain a patterned conductive area, for example to selectively short only certain ones of contacts 216.
  • the sticker may sit on smart-card style connectors of the card.
  • the "sticker" may include electronics, for example a capacitor, a resistor or a ROM, for programming the card.
  • the sticker may include a code generating circuitry, with card 200 serving as an amplifier for generating an output signal.
  • the sticker may affect the capacitance or the inductance of the connection between the electrodes.
  • the sticker may be magnetic, and affect a reed-switch embedded in card 200.
  • other contact-less coupling methods known in the art may be used.
  • a display (not shown), such as an LCD display may be used to display endorsements.
  • card 200 includes a switch (not shown) for sending the above transactional information.
  • a switch for sending the above transactional information.
  • a plurality of switches are provided, one for each endorsement.
  • the switches may be, for example, on an opposite side of card 200 from their respective endorsement. Possibly, a switch is not functional if a sticker is not placed in its respective endorsement area.
  • the sticker itself functions as a switch, selectively shorting (or otherwise affecting the electrical behavior) of contacts 216.
  • Fig. 3 is a schematic side illustration of a modular switch 300, in accordance with an exemplary embodiment of the invention.
  • Switch 300 comprises a base 302 and an upper portion 304 separated from base 302, such that when pressure is applied to upper portion 304 an electrical short is formed between base 302 and upper portion 302.
  • a resilient filling my be provided between the two switch parts.
  • the contact is formed between the center of portion 304 and base 302.
  • base 302 has an adhesive bottom, for attachment to card body 202.
  • one or more spikes 306 are formed on the bottom of base 302 such that when base 302 is brought against card body 202, the spikes penetrate into card body 202 and complete an electrical contact.
  • contacts 216 FIG. 2 can be coated with a protective layer against accidental electrical contact.
  • Such a spike arrangement may also be used for stickers that close contacts, as described above.
  • switch 300 generates a "click" sound when pressed.
  • card 200 generates an audible feedback prior to or after an ultrasonic coded signal is sent to browser 104 form card 102.
  • the feedback is from receiver 108.
  • activating the car generates a feedback by virtue of causing browser 104 to download a WWW page, for example a shopping page.
  • a WWW page for example a shopping page.
  • Such a page can be navigated using a single switch, for example, by allowing only one activity at any pot or by distinguishing single and double depressions of the switch.
  • Such depressions do not usually require an in-depth authentication, however, a counter update may be provided to counter distributor 116.
  • the counter may advance only every few depressions and/or after even only one depression if a sufficient time (e.g., 2 minutes) elapsed.
  • cardholders can use their cards to (i)
  • Fig. 4 is an overview of an exemplary process of ComSense card authentication, in accordance with an embodiment of the present invention.
  • One exemplary feature that differentiates the instant card, in some embodiments of the invention, from an ordinary bank card is the flat button embedded in the corner of the card.
  • This button is a switch, which the user squeezes between two fingers — typically the thumb and forefinger — to activate the card.
  • the exemplary card features the following technical characteristics:
  • the card is optionally manufactured to comply with the requirements of the relevant portions of ISO 7810, ISO 7811 and ISO 7816.
  • the ComSense electronic module is delivered to a Visa certified card manufacturing facility where it is further processed into a card.
  • the plastic sheets containing the appropriate graphics and logos will be produced in this facility utilizing industry standard materials and processes and under the controls of a Visa certified security system.
  • the ComSense electronic modules will be laminated within the plastic sheets. Following lamination, the cards will be singulated and electrically tested. The cards will then be further processed utilizing industry standard equipment and processes. That certified facility will attach holograms and signature panels and will transfer the cards into Issuer's possession for secure shipment to the designated personalization facility.
  • the cards can then be embossed and programmed utilizing industry standard processes and equipment. While embossing practices and specifications vary somewhat, the embossable area will likely be slightly reduced, as compared to most standard credit cards, due to the presence and layout of electronic components within the current card design. Key management ComSense will have keys generated for the cards.
  • ComSense will provide Issuer with a one-way, MD-5 hashed database of calculated transmissions per card. ComSense will transfer that database to the location of the Authentication Server; namely, where the OLA servers are hosted.
  • Fig. 5 illustrates the process of key generation, management, and the creation of hash databases bearing a one-to-one relationship with the set of one-time codes that each card is capable of transmitting, in accordance with an embodiment of the present invention.
  • the ComSense solution for Issuer involves a hybrid scheme that combines web-based software and client-based software. Specifically, the scheme involves: • Integrating transient clients (ActiveX for IE; Java applet for Netscape) in a Issuer login page and elsewhere on the Issuer website, as desired. • Installing persistent client or "tray" application upon running the ComSense Install wizard.
  • the transient client provides control of card reception as a web-based service. This capability enables cardholders to use their card from any computer that is equipped with an operational sound system, microphone and connected to the Internet — even if the computer does not have the ComSense software installed as a tray application.
  • the persistent client application provides an auto-launch feature and one-click access from trusted platforms.
  • Fig. 6 illustrates the interrelationships of the system components of the ComSense solution for Issuer, in accordance with an embodiment of the present invention.
  • Server and database software
  • the server can run, for example, under WindowsNT, Sun Solaris operating system, or some other operating system to be requested by Issuer.
  • the card transmission database can run, for example, under Microsoft SQL.
  • the user activates the card in conjunction with the tray application or with the transient client included in the Issuer login page. In either case, the client PC receives the card's transmission.
  • the PC then sends the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial number) to the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial number) to the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial number) to the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial number) to the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial number) to the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial number) to the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial number) to the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial number) to the signal in its original encrypted form (i.e. plain card serial number and encrypted counter + card-specific second serial
  • the server which resides in a secured location, uses the card serial number to query the hashed list of the card's possible transmissions.
  • the server compares the counter with the previous counter (the current counter must be greater than the previous counter).
  • the server updates the counter value so that the system is prepared for the next authentication request emanating from that card. Please note the following optional points regarding the system's architecture:
  • the Authentication Server is an independent component in the overall architecture of the system.
  • the Authentication Server may reside on the same Intranet as the Issuer servers; therefore, the data that transfers between the servers is internally safe.
  • Fig. 7 is an illustration of the system data flow, in accordance with an embodiment of the present invention. Registration
  • Issuer can design and implement a web-based interface that handles card registration for online verification and authentication. Issuer can also be responsible for managing user registration status. Thus, Issuer can therefore be responsible for managing all aspects of the registration process, including preventing duplicate or false registrations.
  • the Authentication Server can, as a minimum, validate a ComSense card but not associate the card with any other data.
  • the Authentication Server perceives a card to be active and valid from the moment its unique transmissions database is appended to the card's database.
  • ComSense will provide Issuer with its communications receiver layer to implement on an Issuer Card web-based services login page.
  • the communications layer can, for example, support both MS Internet Explorer (version 4.0 or higher) and Netscape's Communicator (version 4.06 or higher).
  • the communications layer comes in two versions: ActiveX for IE users and a Java applet for Netscape users.
  • the communications layer receives the transmission from the card and sends it to the authentication server. Both versions of the communications layer can come with a graphical user interface. In either form (transient or persistent), the client will authenticate to a specific predefined Issuer/Issuer websites or Internet services specified by Issuer.
  • ComSense can modify the comm layer to additional Issuer/Issuer services as requested. Retrieving card serial number
  • ComSense will provide Issuer with an interface for extracting the card serial number from a given card transmission, so as to allow for parallel processing of data and avoiding possible bottlenecks in Issuer's implementation of business rules. Through this interface, Issuer will receive a given card's serial number as soon as it enters the system and even before the system sends that number to the Authentication Server. Auditing: server-side
  • ComSense software will include logging features for collecting data related to user login and transactions.
  • the software may include logging of at least the following data: Timestamp(date and time), Card serial number, Card signal (transmitted data), Card counter, IP address of the requesting machine, Authentication result.
  • Issuer will correlate that data with data from its transaction system to cross-reference when a card is operated to effect a transaction, and the size of that transaction and resulting interchange fee. This information can be used to calculate the Incentive payments due ComSense.
  • the ComSense software knowingly collect user data that is not relevant to the applicability of the software.
  • the resulting traffic database will belong to ComSense Technologies Ltd.
  • ComSense will periodically obtain an electronic copy of the database.
  • Issuer will also share with ComSense other relevant data collected by Issuer's login and transactions logging systems and, in particular, data that relates to how often users enter Issuer services with or without using the ComSense card. From time, to time, Issuer may also collect data from cardholders relating the card's effectiveness and usability that ComSense might find useful for future product enhancements or marketing. Alternatively, ComSense will collect the data and distribute it to the issuer. Implementing by Phone
  • That comm layer can reside in a number of central locations in the phone network.
  • the comm layer can reside on equipment at the local POP, at the Interlata or interexchange connection point, at the equipment location of the carrier providing toll free service, at the call center maintained by the service associated with the phone number dialed.
  • the comm layer could also be housed in CPE equipment itself. That would allow individual callers to authenticate themselves for secure conversations. Using bi-directional, two cardholders could each simply hold their cards up to their handsets. One cardholder would activate his card, and the other would receive the transmission remotely over the phone. This method is ideal for exchanging information quickly by phone such as contact information, or for authenticating for conference calls or other private and secure communications.
  • Comm Layer housed at a server, such as the voice dialing server. Many cellular phone systems now offer voice dialing. Often, that functionality is largely server-based. Activating the phone immediately establishes a connection with a server hosting voice dial functionality. In that environment, housing the comm layer at the server allows the cardholder to open or activate his phone, and then activate the ComSense card when prompted to speak a name for voice dialing. The server/comm layer would receive the card transmission, and take appropriate action.
  • Those actions could include without limitation (i) looking up the phone number associated with the card service and then dialing the number; (ii) looking up the wireless web service associated with that card, and launching and logging into that service on the customer's cell phone.
  • Sound signal reaches cell phone 3. Sound signal carried from phone to cell, and from cell to a central server, such as a voice dialing server
  • a signal with the card's one time code is sent to that website or phone number, where the code is authenticated, for example using the hash database lookup method described above.
  • the user is authenticated by the service, which is by now in direct communication with the cell phone.
  • the user receives personalized web content, or instructions over the dial-up service Client software
  • ComSense provides a single tray application that, after installation, runs automatically each time the user turns on the PC and Windows opens.
  • Installing the tray application software is a short and easy process. During installation, the Install wizard prompts the user to validate his/her card. This process, if desired by the user, establishes the installed computer as a "trusted platform" for the unique card (and unique user). Once installed, the ComSense tray application enables the cardholder to use the card to gain quick and secure access to Issuer's Issuer services.
  • a ComSense-branded tray icon ( ⁇ * ⁇ s or another logo) appears in the Task Bar to indicate that the ComSense application is active. Each time the user activates the ComSense card, this tray icon changes color (currently from yellow to green, and back to yellow shortly thereafter). The user can disable the software at any time.
  • the software optionally includes an "uninstall” feature.
  • the ComSense tray application validates the card's transmission. If a transmission is valid, the application performs one of the following:
  • the browser On a trusted platform, the application launches the browser, opens the predefined, auto-launch Issuer website, and logs in the user. On a not-trusted platform, after activating the card, the user will also supply his/her password. • If the browser is open but is not displaying a web page from the predefined, auto- launch Issuer domain: In the case of a trusted platform, opens a new browser window, opens the predefined auto-launch Issuer website, and logs in the user, h the case of a not-trusted platform, after activating the card, the user will also supply his/her password. Note that the need to present a physical card and provide a password to authenticate oneself is the same authentication norm as used by ATMs.
  • the ComSense solution captures the user's request as soon as it is made. This auditing process is conducted in the same manner as— and in addition to- auditing on the server-side.
  • the ComSense card provides secure access and transactions on the web.
  • the card transmits one-time codes and a card serial number.
  • the application Upon determining that a valid transmission has taken place, the application forwards the card transmission to the ComSense Authentication Server.
  • the server uses an MD-5 one-way hashed database of all cards and their possible valid transmissions for card verification and authentication. At no point during the authentication process do any of the machines that make up the system architecture know or use the secret ciphering keys. In fact, the keys do not exist in any of the machines within the system architecture. Implications of the security scheme:
  • Each ComSense card is unique. Different cards enable access to different accounts.
  • the authentication server holds an MD-5 hashed database. This means that, even in the unlikely event of the database being acquired by an unauthorized party, it is virtually useless. The card cannot be used outside the system.
  • This system can be modified to allow the same card to authenticate to multiple services. Instead of just one, multiple hash databases are created for each card, corresponding to a different hash function in each case.
  • FIG. 8 is a schematic illustration of an exemplary system architecture, in accordance with an embodiment of the present invention.
  • ComSense will manufacture the Issuer cards with the same graphical design as that of previously distributed Issuer cards.
  • the cards will contain the ComSense-branded button and logo, as illustrated below:
  • the button will be of a fixed size, occupy a fixed location on both sides of the card, and have graphics that mark it as a point that the user needs to squeeze.
  • the ComSense logo will appear in one place on the front and back of the card, at the location of the switch.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • Software Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

Cette invention concerne une méthode de transaction et d'authentification, consistant à recevoir une information sur une transaction au moyen d'une ID carte, d'un code et d'un compteur à un premier emplacement; transmettre sélectivement ladite information à au moins un serveur d'authentification parmi une pluralité de tels serveurs, appliquer une fonction de hachage à ladite information, et faire correspondre ladite information après hachage avec une base de données de tronçons d'information valables sur au moins l'un des serveurs d'authentification.
PCT/IL2001/000758 1999-10-04 2001-08-14 Authentification par serveurs multiples WO2002014974A2 (fr)

Priority Applications (9)

Application Number Priority Date Filing Date Title
US09/853,017 US7280970B2 (en) 1999-10-04 2001-05-10 Sonic/ultrasonic authentication device
AU2001282453A AU2001282453A1 (en) 2000-08-14 2001-08-14 Multi-server authentication
EP02718485A EP1407418A4 (fr) 2001-03-22 2002-03-21 Fabrication de dispositifs d'identification autoalimentes
AU2002241234A AU2002241234A1 (en) 2001-03-22 2002-03-21 A method and system for remotely authenticating identification devices
EP02707082.0A EP1381985A4 (fr) 2001-03-22 2002-03-21 Procede et systeme d'authentification a distance de dispositifs d'identification
PCT/IL2002/000235 WO2002076717A2 (fr) 2001-03-22 2002-03-21 Fabrication de dispositifs d'identification autoalimentes
PCT/IL2002/000236 WO2002078199A2 (fr) 2001-03-22 2002-03-21 Procede et systeme d'authentification a distance de dispositifs d'identification
AU2002249532A AU2002249532A1 (en) 2001-03-22 2002-03-21 Manufacture of self-powered identification devices
US10/668,109 US9219708B2 (en) 2001-03-22 2003-09-22 Method and system for remotely authenticating identification devices

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
IL137854 2000-08-14
IL13785400A IL137854A0 (en) 2000-08-14 2000-08-14 Multi-server authentication
US27799601P 2001-03-22 2001-03-22
US60/277,996 2001-03-22

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/853,017 Continuation-In-Part US7280970B2 (en) 1999-10-04 2001-05-10 Sonic/ultrasonic authentication device

Related Child Applications (2)

Application Number Title Priority Date Filing Date
PCT/IL2002/000236 Continuation-In-Part WO2002078199A2 (fr) 2001-03-22 2002-03-21 Procede et systeme d'authentification a distance de dispositifs d'identification
US10/668,109 Continuation-In-Part US9219708B2 (en) 2001-03-22 2003-09-22 Method and system for remotely authenticating identification devices

Publications (2)

Publication Number Publication Date
WO2002014974A2 true WO2002014974A2 (fr) 2002-02-21
WO2002014974A3 WO2002014974A3 (fr) 2002-06-20

Family

ID=26323967

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2001/000758 WO2002014974A2 (fr) 1999-10-04 2001-08-14 Authentification par serveurs multiples

Country Status (2)

Country Link
AU (1) AU2001282453A1 (fr)
WO (1) WO2002014974A2 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003085925A1 (fr) * 2002-04-04 2003-10-16 Activcard Ireland Limited Procede reparti et systeme d'authentification
WO2004004273A1 (fr) * 2002-06-28 2004-01-08 International Business Machines Corporation Procede et systeme d'authentification determinee par l'utilisateur et ouverture de session unique dans un environnement federe
US20050177484A1 (en) * 2004-01-16 2005-08-11 Keith Jentoft Audio-equipped transaction card systems and approaches
WO2009004508A1 (fr) * 2007-06-29 2009-01-08 Nxp B.V. Ppprocédé pour une authentification cryptographique
US9607475B2 (en) 1998-09-16 2017-03-28 Dialware Inc Interactive toys
GB2551808A (en) * 2016-06-30 2018-01-03 Razorsecure Ltd Data validation

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000021020A2 (fr) 1998-10-02 2000-04-13 Comsense Technologies, Ltd. Carte permettant d'interagir avec un ordinateur
US6607136B1 (en) 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
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

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023509A (en) * 1996-09-30 2000-02-08 Intel Corporation Digital signature purpose encoding
US6119228A (en) * 1997-08-22 2000-09-12 Compaq Computer Corporation Method for securely communicating remote control commands in a computer network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023509A (en) * 1996-09-30 2000-02-08 Intel Corporation Digital signature purpose encoding
US6119228A (en) * 1997-08-22 2000-09-12 Compaq Computer Corporation Method for securely communicating remote control commands in a computer network

Cited By (11)

* Cited by examiner, † Cited by third party
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
WO2003085925A1 (fr) * 2002-04-04 2003-10-16 Activcard Ireland Limited Procede reparti et systeme d'authentification
US7430667B2 (en) 2002-04-04 2008-09-30 Activcard Ireland Limited Media router
WO2004004273A1 (fr) * 2002-06-28 2004-01-08 International Business Machines Corporation Procede et systeme d'authentification determinee par l'utilisateur et ouverture de session unique dans un environnement federe
KR100800339B1 (ko) * 2002-06-28 2008-02-04 인터내셔널 비지네스 머신즈 코포레이션 제휴 환경에서 사용자에 의해 결정된 인증 및 단일 사인온을 위한 방법 및 시스템
US20050177484A1 (en) * 2004-01-16 2005-08-11 Keith Jentoft Audio-equipped transaction card systems and approaches
US8447668B2 (en) * 2004-01-16 2013-05-21 Keith Jentoft Audio-equipped transaction card systems and approaches
US8751349B1 (en) 2004-01-16 2014-06-10 Keith Jentoft Audio-equipped transaction card systems and approaches
WO2009004508A1 (fr) * 2007-06-29 2009-01-08 Nxp B.V. Ppprocédé pour une authentification cryptographique
GB2551808A (en) * 2016-06-30 2018-01-03 Razorsecure Ltd Data validation

Also Published As

Publication number Publication date
AU2001282453A1 (en) 2002-02-25
WO2002014974A3 (fr) 2002-06-20

Similar Documents

Publication Publication Date Title
US11647385B1 (en) Security system for handheld wireless devices using time-variable encryption keys
US8751801B2 (en) System and method for authenticating users using two or more factors
US9325701B2 (en) Method and apparatus for the secure authentication of a web-site
AU2006312456B2 (en) Authentication for service server in wireless internet and settlement using the same
US20030191721A1 (en) System and method of associating communication devices to secure a commercial transaction over a network
US8954745B2 (en) Method and apparatus for generating one-time passwords
US20080046988A1 (en) Authentication Method
EP1636934A1 (fr) Authentification hybride
US11403633B2 (en) Method for sending digital information
CN102088353A (zh) 基于移动终端的双因子认证方法及系统
US7690027B2 (en) Method for registering and enabling PKI functionalities
WO2002014974A2 (fr) Authentification par serveurs multiples
WO2002078199A2 (fr) Procede et systeme d'authentification a distance de dispositifs d'identification
AU2004312730B2 (en) Transaction processing system and method
EP3570518B1 (fr) Systeme et procede d'authentification utilisant un jeton a usage unique de duree limitee
WO2009075627A1 (fr) Système d'ouverture de session
KR20020053791A (ko) 지문인식형 이동통신단말기를 이용한 개인인증방법 및이를 위한 개인인증시스템
KR20070076577A (ko) 기록매체
KR20070077484A (ko) 정보처리방법

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 PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA 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 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 PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA 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 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

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1)EPC - NON PAYMENT OF THE NATIONAL BASIC FEE, SEARCH FEE, DESIGNATION AND EXAMINATION FEE

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP