WO2021229584A1 - System and method to support message authentication - Google Patents

Abstract

The invention disclosed herein provides a system and a method designed to authenticate any sort of message by any kind of messaging platform. The system and method are best described as offline peer-to-peer authentication (among two or more members) by means of creating a One Time Authentication Code (OTAC). The term Peer to peer will refer to the offline authentication aspect of the present invention in a way that indicates a personal embedding of the OTAC in a message by the sender and personal verifying it by the receiver. The architecture and method of the present invention relate to generating an OTAC, which could be included in any non-encrypted message and could be checked for authenticity by the receiving part of said message. The architecture and method of the invention allows authenticating not only the identity of the sending party but also sensitive data included in the message.

Description

Description

Title of Invention: System and method to support message authentication

Technical Field

[0001] One or more embodiments of the invention generally relate to a system for message authentication. More particularly, one or more embodiments of the invention relate to a message authentication system through compound authentication Key.

Background of the invention

[0002] The following background information may present examples of specific aspects of the prior publications (e.g., without limitation, approaches, facts, or common wisdom) that, while expected to be helpful to further educate the reader as to additional aspects of the prior publications, is not to be construed as limiting the present invention, or any embodiments thereof, to anything stated or implied therein or inferred thereupon.

[0003] The prior publications regarded hereinafter will address two major subjects. The first one will relate to the art of messaging security and authentication. The other to the technology of one-time passwords (OTP’s) and more specifically a unique device designed to generate them.

Technical Problem

[0004] With increasing complexity and expansion of business transactions, and other executable action orders, improvement of the security of online and other remote transaction becomes an essential pre-requisite to enable the authentication of the information in such transactions in particular verifying the true authentication of the sender, and the details of the transaction itself. As regard a highly-sensitive document, the parties involved, i.e., the sender as well as the receiver need to exchange the data in a verifiable and authenticated manner in order to prevent theft, fraud or other improper actions by a third unauthorized party, and allow said verifying and authentication to be repeated in any time by any party. In that objective, information security technology can be applied to verify the sanctity of the data. As a method of achieving the verification, a technique called message authentication is generally used, where a transmitter and a receiver have a common secret key, and the receiver uses a cipher or a hash function to confirm that data are from the transmitter having the secret key. In other setting a username/password is generally used to authenticate a remote user. However, passwords are susceptible to be hacked thus subsuming the identity of an authorized personnel and increasing the propensity of data pilferage.

[0005] One of the problems to be solved is known as business email compromise, or “CEO fraud”, It relates to a scam in which hackers spoof company email accounts of senior executives or the CEO, impersonate them, and send or tamper emails to financial departments trying to deceive them into executing payments. Estimated losses on this account exceeds in the USA alone $3Billion a year.

[0006] There is a need in the art for an authentication method, that will allow authenticating a message, by providing a coding scheme that could authenticate the sender, sensitive data (sums, orders, etc.) that would work independently from any messaging system, and wouldn’t require a connection to a mutual server. Preferably that wouldn’t require any network connectivity at all.

Prior publications

Patent Literature

[0007] Quite a number of attempts in authenticating messages are in vogue in patent literature

[0008] PTL1 : US20030041242A1 , titled, “Message authentication system and method” discussion of a message authentication system that generates a message authentication code (MAC) is talked about. It uses a single iteration of a keyed compression function when a message fits within an input block of the compression function, thereby improving efficiency. For messages that are larger than a block, the MAC system uses nested hash functions. The MAC system and method can use portions of the message as inputs to the nested hash functions.

[0009] PTL2: In another application, US20150113615A1 titled, “Text message authentication system” a systems and method for authenticating users is presented. A system can send a passkey to a user interface of a known device. A user can then send a messaging service message with the passkey from a second device to the system. After receiving the message from the user, the system can extract the passkey from the message, and compare the received passkey against the passkey originally sent to the user. The known device and the second device can each have separate and unique device identifiers

[0010] PTL3: In the patent, US20150304293A1 titled, “Message authentication system and message authentication method” discussion of a message authentication system used in a multihop network and including a server 30 and multiple nodes 1 which transmit data to the server 30 is made. Each of the nodes 1 includes: a tag generation unit which uses a private key shared with the server to calculate a tag as a message authenticator corresponding to the data; and a parity tag generation unit which uses the tag to generate a parity tag composed of parities calculated as error-correcting code. The node 1 generates the parity tag corresponding to the tags created by the node 1 and child nodes of the node 1 , and transmits the parity tag to a parent node or the server together with the data.

[0011] All said methods are practically not suitable to be performed in manual authentication (Hence, do not fit for a standalone authentication device).

[0012] The most common and standard way for authenticating messages in digital communication (without encrypting the message itself) is by using a message authentication code (MAC), sometimes known as a tag , being a piece of information used to authenticate a message — in other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed,

[0013] A practical and more immune to attacks method is the HMAC (defined in rfc2104 and used in many scenarios such as in IPSec and TLS protocols).

HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) is a specific type of MAC involving a cryptographic hash function and a secret cryptographic key. As with any MAC it may be used to simultaneously verify both the data integrity and the authentication of a message. Any cryptographic hash function, such as SHA258 or SHA-3, may be used in the calculation of an HMAC; the resulting MAC algorithm is termed HMAC-X, where X is the hash function used (e g. HMAC- SHA258 or HMAC-8HA3). The cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function, the size of its hash output, and the size and quality of the key.

[0014] HIVIAC does not encrypt the message. Instead, the message (encrypted or not) must be sent alongside the HMAC hash. Parties with the secret key will hash the message again themselves, and if it is authentic, the received and computed hashes will match,

[0015] The HMAC is usually computed by some software (that may reside in the messaging application or be called by it) and the resulting value is added to the message. However, such a code has a few limitations: a) The generated key is too complex and long (e.g. 160bit long) to be manually inserted to a message or to a verification device or even to manually inspect (e.g. reading on display). Therefore, such keys are not practical for use in hardware tokens and such devices where a person is required to work with the code. b) The authentication is based on the sender using the correct shared secret key. If multiple users use the same key then the specific sender cannot be authenticated. c) The method is software based and hence is vulnerable to malware,

[0016] To overcome limitation of using such long keys in operations where people are involved, there is the One-Time-Password (OTP) method. The OTP method is usually based on a first step of doing HMAC and then truncating the result in a certain way to a much easier to handle one-time code. To make the code one time the HMAC is acting on the secret shared key as before but now the data to be authenticated is not the message data but some one-time value such as a counter (HOTP) or timestamp (TOTP) and so the resulting code is useable for users to type or read and can be generated by tokens.

[0017] However, when in current art HMAC is used for creating OTP they do not protect a message data. The OTP is usually just used for user’s authentication and then, usually a secure link is opened to transfer the data. I.e. the OTP code itself does not enable data verification and hence after being validated it is not a part of the message

[0018] Some of the discussed methods include A token -a device that generates the OTP and displays it to the user or communicates it to the system. (It should be noted that the term “token”, that is used extensively in this document, may have multiple meanings, and so, for clarification: in this document token is an electronic device). OTP tokens exist in various forms and functionalities in the industry and in patents. The main task of an OTP token is to generate OTP (One Time Password) for the purpose of personal identification that can be verified by verification software usually running on some server. Many enterprises provide such tokens to employees to allow them secure remote access to the enterprise network. Also, various Internet companies (e.g., Google) participate in creating standards for OTP generation that will allow users to log in to their services.

[0019] PTL.4: US8087074 describes the basic aspects of current OTP tokens. a) The token generates the OTP using a secret key and a one-time value (in this case a counter). b) The token sends the OTP to a validation server. c) The validation server uses the same values used by the token to check the OTP. d) There is a need for synchronization mechanism between the onetime value of the token and the validation server.

[0020] PTL.5: US8959350 discloses a method for performing a command on a token. The method includes receiving a first command authentication message digest (CAMD), a command, and scrambled data from a sender, and making a first determination that the sender is allowed to send commands to the token. The method further includes, based on the first determination, generating a second CAMD on the token using the command, the scrambled data, and an Administrative Command Authentication Secret (ACAS), making a second determination that the first CAMD and the second CAMD match, and based on the second determination, performing the command by the token.

[0021] PTL6: US9218476 Discloses a one-time password (OTP) based security scheme is described, where a provider pre-generates a number of Verification codes (e.g., OTP codes) which will be valid for a predetermined interval. The provider then encodes the verification codes (e.g., by hashing each code with a time value), and stores the verification codes into a data structure. The data structure can be provided to a verification system that can use the set of pregenerated OTP codes to authenticate requests received from users having personal security tokens.

[0022] PTL.7: US20140337957A1 disclosure is generally directed to a hardware token for completing an out-of-band authentication. In one embodiment, the hardware token performs a method that comprises: receiving an out-of-band encryption key from a client computing device; deriving a security credential that uniquely identifies the hardware token; transmitting the derived security credential and received out-of-band encryption key over the out-of-band communication channel to a network backend over a wireless network; receiving an in-band encryption key over the out-of-band communication channel; and transmitting the received in- band encryption key to the paired client computing device.

Non-Patent Literature

[0023] There are a several OTP tokens in the market such as Yubico YubiKey 4 - USB- A, Two-Factor Authentication, FIDO U2F Security Key, OnlyKey Color, DIGIPASS SecureClick FIDO U2F Security Key, Feitian ePass NFC FIDO U2F Security Key and SafeNET Authentication tokens, all of them are designed to be used for user authentication at login.

[0024] NPL1 : Yubico YubiKey 4 - USB-A, Two-Factor Authentication: The YubiKey is a popular 2-factor hardware authentication device manufactured by Yubico. It supports the Universal 2nd Factor (U2F) protocol, which is an open authentication standard supported by Google Chrome, Dropbox, Facebook, and many other influential tech companies.

[0025] The fourth generation of the YubiKey is light, small, and extremely durable, designed to survive just about anything. It plugs into USB Type A. It is expected to have out-of-the-box compatibility with most websites and applications.

[0026] NPL2: FIDO U2F Security Key:The FIDO Alliance launched in February 2013 to improve the interoperability among authentication devices. The founders of the organization included PayPal and Lenovo, and FIDO now has almost 300 members, including MasterCard, Visa, Microsoft, Samsung, Intel, and Google, just to name a few. Hardware tokens that comply with FIDO specifications are considered to be extremely secure, reliable, and widely supported. The FIDO U2F Security Key supports the Chrome web browser on Windows, Mac, and Linux as well as a host of other services and applications.

[0027] NPL3: OnlyKey Color: The OnlyKey Color offers a unique take on 2-factor hardware authentication. It combines a password manager, a two-factor token, and offline encryption key storage into a single package. It has an integrated touch keyboard. The OnlyKey Color identifies as a standard USB keyboard, allowing the user to circumvent keyloggers. It supports all standard 2-factor authentication methods like U2F, YubiKey compatible OTP, and Google Authenticator. The integrated LED visually informs the user whether the entered password was right or the wrong.

[0028] NPL4: DIGIPASS SecureClick FIDO U2F Security Key: This FIDO-compatible 2-factor authentication token makes hardware authentication even more secure. It’s not unheard of for employees to forget their hardware 2-factor tokens at work. Should this happen with the DIGIPASS SecureClick FIDO U2F Security Key, it would still be impossible for an attacker to get in because a press of a small Bluetooth button with a 2-year lifespan is required to complete the authentication.

[0029] NPL5: Feitian ePass NFC FIDO U2F Security KeyThe Feitian ePass NFC FIDO U2F Security Key is aimed also for people who need to be protected even when on the phone. It’s compatible with all modern operating systems and features an NFC chip for wireless authentication. The user should place it near her smartphone to authenticate her online payments and website log in attempts. The Feitian ePass is FIDO-certified.

[0030] NPL6: SafeNET Authentication tokens: Generate dynamic one-time passwords (OTPs) for properly authenticating users to critical applications and data, whether on an authentication token, mobile device, or grid-based authentication. SafeNet OTP authenticators are available in both time- and event-based versions, never expire, and require no battery replacements. They also comply with OATFI standards and are ideal for remote access solutions. The following Tokens are offered:

[0031] None of said prior known tokens could be used for direct person to person, message authentication that includes sensitive data authentication or a complete offline functionality.

Summary of Invention

[0032] The core of the invention disclosed herein is to provide with a system and a method, designed to authenticate any sort of messages, by any kind of messaging platform. The system and method are best described as offline-peer to peer authentication (among two or more mebers) by means of creating a One Time Authentication Code (OTAC). The invention relies on a novel system and a method that has never been used in the art of OTP’s nor in the art of message authentication. In this specification the term Peer to peer will refer to the offline authentication aspect of the present invention, in a way that indicates a personal embedding of the OTAC in a message by the sender and personal verifying it by the receiver.

[0033] The architecture and method of the present invention relates to the generating of a OTAC, that could be included in any non-encrypted message and could be checked for authenticity by the receiving part of said message. The architecture and method of the invention allows to authenticate not only the identity of the sending party but also a sensitive data included in the message.

[0034] The invention further allows the recheck of the authenticity of a method in any time thus allows to verify the correct usage of the method, and prevent false claims of usage thereof. Solution to Problem

[0035] Embodiments of the present invention are best understood by reference to the detailed figures and description set forth herein.

[0036] Embodiments of the invention are discussed below with reference to the Figures. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments.

[0037] It is an object of the present invention to provide a method and a system that use proven and industry preferred algorithms such a HMAC and HOTP/TOTP in a vast new ways and to perform a completely new tasks; i.e. : to create a code that is both useable (e.g. a 6 digit number), so it can be used by manually operated Tokens, be one-time, be malware agnostic, and is also added to the message (including non-digital messages) to enable authentication of both at least some parts of the message’s data and authenticate a specific user even within a group of users using the same shared secret key.

[0038] An aspect of the invention is to provide a method and system in providing a group of people with a mean to communicate using any messaging method such that the identity of the sender and the sensitive data that may be contained in the message can be authenticated.

[0039] In another aspect of the invention, the Verifiable and authenticated communication is achieved through an architecture that could be incorporated in a small electronic device, denoted herein “Token” that is used by the group members to achieve this goal. Such Token could also be a secure element within another device such as a smartphone provided it supports all functionalities as described herein. Such secure element (e.g. secure enclave) should be enahanced with a dedicated output to be used as the Token.

[0040] In an aspect of the invention, the message sender can use the Token to generate OTAC (One Time Authentication Code) that she, manually or via an application, then inserts to the message (along with the OTV - one-time-value - that was used for the OTAC generation) and the receiver of the message can use the received OTV and OTAC and the data items to be verified as explained in details below to authenticate the identity of sender and the said data items in the message.

[0041] In this aspect of the invention, the message sender incorporates a unique one time value (OTV) in the generation of the OTAC wherein the OTV indicates a non- reusable value. (E.g., the specific date and time, of generation; a continuous serial number etc.) In that setting, the OTAC generation uses the OTV in order to remove the possibility to generate a duplicate of a legitimate transaction.

[0042] The main aspect of this invention is the generating of an OTAC using: a) OTV b) Group key c) And Optionally: a. The Identity of the sender b. the identity of the receiver c. At least one data item to be verified

[0043] Typically, data item would be sensitive data that could be of importance or likely to change in case of a fraud (e.g. receiver ID, bank account, sum etc.)

[0044] It is an object of the present invention to provide with an OTAC system and method that allow complete decentralized peer-to-peer operation where each side can generate and validate OTACs. That as opposed to prior known OTP Tokens and systems are all client-server based.

Advantageous Effects of Invention

[0045] The invention disclosed herein sets itself apart from prior known systems and methods.

[0046] The said Token embodied with the features of being personalized and enrolled to a specific group by the users entails no specific production effort and no reliance on a Token’s S/N or such identification that creates the risk of a stolen Token, although in some embodiments the Token’s S/N could be utilized as set forth hereinafter. [0047] The method involving OTAC generation with a message despite being shared amongst a group of people has the unique attribute of authenticating a specific sender.

[0048] The method of generating OTAC to a message using an embedded OTV enables authentication anytime after receipt of the message, and prevents future messages (of the same content from same sender) from having the same OTAC.

[0049] The uniqueness of the generated OTAC lies not only on the shared secret key and the OTV but also on the specific user ID and the additional sensitive data (if used) from the message that are utilized for verification, thus ensuring that data had not been tampered or changed.

[0050] The method also enables the receiver to store OTV’s received from a specific sender, that results in a denial of any fake message fabricated by a hacker, having the same OTV of a previous message.

[0051] Furthermore, if the receiver ID is used as the at least one verifiable detail, it will prevent a hacker from sending a duplicated genuine message to a different receiver.

[0052] A comparison of the architecture and method disclosed herein with prior known systems and methods would reveal the novelty and the advances of the present invention:

[0053] The present invention provides an OTAC system and method that allow a complete decentralized peer-to-peer operation where each side can generate and validate OTACs. That is as opposed to prior known OTP Tokens and systems that are all client server based and therefore could usually generate a OTP or rarely validate a OTP but never do both.

[0054] The OTAC system in the present invention could be, according to some embodiments, based also on data that is part of a message and therefore can authenticate not just sender identity but also data. None of the prior known OTPs can authenticate any data. In specific if one of the sensitive data items is the receiver ID than the intended receiver is also verified.

[0055] The architecture of the present invention works peer to peer and allows to send the one-time value (OTV) together with the message and the OTAC. This allows: a) The receiving OTAC can validate the sender and message at any time, multiple times and thus enable verification of proper behavior also by additional parties (e.g., insurance companies as will be discussed in detail hereinafter). b) Unlike prior known technology there is no need for one-time value synchronization between OTAC generator and validator.

[0056] The architecture of the present invention supports multiple users (group) in peer to peer architecture as oppose to prior known technics that support sending and receiving between parties that are selected from a multiuser group only through a common server (centralized star architecture).

[0057] The architecture of the present invention supports later re-validation by a third party, in a secure way (i.e. cannot be corrupted even by the group member themselves). None of the prior known methods provide this capability. This point can be further explained using an example case as follows:

[0058] Suppose a company would like to get an insurance coverage against fraud relating to wired transfer orders. The insurance company may require using authentication method for the wired transfer order. An advantage of the method of the present invention, is that not only it provides with the capability for the insurance company to verify, upon a claim that the method was used, but also it eliminates the possibility of fabricating a fake message by the users in order to cover up their failure to comply with the required method as described below: a) The users cannot use the sender’s Token to create a message after the wire transfer was performed, with an OTV that relates to a time previous to said wire transfer. (This relates to an embodiment where the OTV is linked to time). b) in some embodiments of the present invention there is a logging feature which can be required by the insurance company as mandatory part of a legitimate claim. If a fake message is created post transaction (e.g., via a Token emulation device) the receiving party’s Token will show in its log the time of verification which will be post the wire transfer. In this case “losing” the receiver’s Token or erasing its log by tampering with it will cause insurance claim rejection.

[0059] The OTAC architecture of the present invention characterized in high malware resistance: a) In prior known Tokens that generate code are part of a system that includes a verification by server. Therefore, at the system level it is vulnerable to malware (even if the Token itself has no connectivity feature). In embodiments of the present invention both code generation and verification are done by hardware Tokens and therefore the architecture is not vulnerable to malware. b) In certain embodiments of the present invention where the architecture is embedded in a Token that has some sort of connectivity, then per each such case it is designed so that it is malware resistive and agnostic as follows: i. When working in tandem with a communication device using a dedicated messaging application the communication driver in the Token is limited to specific protocol and message data types which blocks malware from being injected to the Token, and the values of the sender identity and data to be protected are displayed to the user on the Token display so the user can know that the OTAC generated is relevant to the correct data and if a malware in the communication device will change the OTAC or the data in the message actually sent it cannot be authenticated by the Token at the receiving side which also displays the data and OTAC it validates and they need to be identical to the data received in the message which the user can validate himself. (Note: a malware in the communication device cannot create a properly authenticated fake message because it has no knowledge of the secret shared key and have no access to it). Also, it cannot initiate a fake message with the Token since the user’s ACK is required for the Token to provide the application with codes. ii. When supporting logs, the logs are kept in a FIFO memory (or any other structure of dual port memory) that can be read via the interface but cannot be written to via the interface due to hardware restriction. iii. When supporting software upgrade the new software can be written to a buffer that only supports data insertion by the external computer to a specific location as confined by the Token hardware and then the new software is validated by the Token using public key digital signature before loaded to PRG memory. iv. When applying the PAIR method using Token to Token direct communication or via some intermediate device, the protocol is aimed at transferring the Group Key only (or optionally Group Key and User- ID), being one data type, and can be also enforced by hardware although not mandatory. If PAIR uses encryption then the interface allows also the exchange of public keys between the Tokens. This can be done using a second data type or by providing read only access to these values via digital interface.

[0060] The OTAC architecture of the present invention is general purpose, which means, that although it is engineered with accordance to the present invention, it needs not be tailored to any specific organization, or group of organizations or specific standards or applications. Besides the important feature of allowing the users to use any messaging system they want for message creating and communicating, this feature also means: a) No need to set minimum orders b) The Token can be reset, and/or reused at any time and be provided to a different user c) No need to worry if a Token is damaged or lost or stolen - the Group Key can always be changed by the group at any time and any data in that Token loses its sensitivity.

[0061] The present invention uses an OTV as part of its OTAC generation and verification, the concept of the OTV will be better understood with relation to the following explanation: The OTV (One-Time Value) is a value generated by the Token as part of the OTAC generation (GEN) procedure. The OTV must be unique per the generating Token (hence one-time) so even if it was eavesdropped it cannot be reused by the attacker to “replay” the message. Uniqueness is required for at least the entire life-cycle of that Token within a specific group.

[0062] The uniqueness could be easily verified by the OTV generator itself (that the new value has never been used before) as well by any verification Token (that the received OTV from the specific sender has never been received before). In a preferred embodiment of this invention the OTV values are always increasing and hence if the last used OTV (by the generation Token), or the last received OTV from that sender (by the verifying Token) is smaller than the currently generated/received OTV it is clear it has never been used/received before. To enable this test the last generated OTV (or potential OTV, i.e. most updated Token’s timestamp) as well as the last received OTV from each sender are saved in the persistent memory of each Token. In order to enable checking messages in order different from the order of their generation, all or some received OTV’s can be stored in the Token’s persistent memory. In the case that only N OTV’s are stored then it is assumed that older messages are no more relevant. This also enables a recheck of a message with a notification to the user that this message has been checked before.

[0063] There are various methods for OTV generation. In one embodiment of this invention The OTV is based on a counter that increments by 1 per each OTAC generation. In such a case the initial value can be set at Token initialization or creation and saved to a persistent memory (e.g., CRPT). Then at each following OTAC generation the OTV value is created by retrieving the current saved OTV from the persistent memory, then increasing it by 1 and using the result as the OTV for OTAC generation that is also saved in persistent memory, replacing the previous saved value. This is probably the simplest way to generate OTV’s but the OTV value cannot be linked to time and so this method is less resistive to the malicious generation of fake messages made to look as if sent at some previous time.

[0064] In another preferred embodiment of this invention the OTV’s are linked to actual time (i.e. some sort of a timestamp). Implementation wise this can be implemented by using the Token itself to count time. The time value can be the accurate time of day by implementing elements such as a GPS receiver that periodically updates the Token’s clock. The time value can also be less accurate (i.e. accuracy depends on the drift in the Token’s hardware clock. This method is simpler and good enough, especially in the case where a battery (at least the one running the hardware clock) is not replaced or recharged during the Token’s life-time. In specific a hardware clock based on commercially available crystal with calibration and temperature compensation as built in hand watches and such other time keeping devices would have better than 4 ppm accuracy which means the time drift over 5 years is less than 10 minutes, which is good enough for the purpose of such Tokens. If the battery running the internal clock is replaced or recharged (i.e. can get fully discharged) then the drift to consider should be the additional time of replacement or from discharged to charging). In the case that GPS or such utility that can provide to the Token from external sources the time of day, is not used, then initialization of the Token’s “timestamp” can be done at Token manufacturing stage or at the personalization or the enrollment procedures. If the current time of day value is used then if the initialization is done during personalization or enrollment procedures the time/data setup procedure should be added to these procedures. However, manual time setup is not really necessary since a simple counter can be used (e.g. that counts seconds from its initialization) and a correlation between an OTV value used at a known time can be used to derive the actual world time/date for any OTV value of that Token. When manual setup is not required and there is no initialization by the manufacturer, initialization can be done by the program inside the personalization or enrollment procedures. (For the purposes of the example described in the figures of this invention it is assumed that the Token arrives from the manufacturer with OTV initialized).

[0065] In an embodiment of this invention the internal “timestamp” of a Token (when is internal counter counting clock pulses based) is periodically saved in the persistent memory (e.g. every 10 seconds). Such timestamp is denoted herein “Token timestamp”. This makes it impossible to create a “past fake” message) because the new potential OTV value after battery replacement or full discharge to recharge duration will start from the value saved in the persistent memory prior to that duration and not from a potentially much earlier value generated at the previous OTAC generation (might even be the initialization value if the Token’s timestamp resets during that time).

[0066] The implementation of such Token “timestamp” may require a hardware device that works as a timer counting seconds (or some other fixed measure of time) that may also be required to interrupt the program periodically to save the current time value in the persistent memory. This hardware device, may be either independent internal or based on external time source such or both (e.g. GPS periodically updating a counter).

Brief Description of Drawings

[0067] The structure, operation, and advantages of the present preferred embodiment of the invention will become further apparent upon consideration of the descriptions set forth herein, taken in conjunction with the accompanying figures (FIGS.). The figures (FIGS.) are intended to be illustrative, not limiting. Although the invention is generally described in the context of these preferred embodiments, it should be understood that it is not intended to limit the spirit and scope of the invention to these particular embodiments.

[0068] Figures 1 through 11 provide examples for a Token with full manual operations. The principles of the systems and method explained there are also applicable to the case of a Token cooperating with a dedicated application in various ways as depicted in Figures 12 and 13 and also to additional embodiments and architectures describes later on without figures.

[0069] [FIG.1] is a schematic block diagram representing the architecture of the system of the present invention.

[0070] [FIG.2] is a flowchart representing an example of the main action of the method of the present invention.

[0071] [FIG.3] is a flowchart representing an example of possible system configuration (CFG) procedure in which the user can make various configuration changes such as creating biometric templates or changing a personal password.

[0072] [FIG.4] is a flowchart representing an exemplary embodiment of the present invention.

[0073] [FIG.5] is a flowchart representing the generation (GEN) module of the present invention.

[0074] [FIG.6] is a flowchart representing the authentication (CFIK) module of the present invention. [0075] [FIG.7] is a flowchart representing an exemplary embodiment of data entry procedure of the present invention.

[0076] [FIG.8] is a flowchart representing the Loader (LDR) module “reset to factory settings” option of the architecture of the present invention.

[0077] [FIG.9] is a flowchart representing the personalization procedure of the present invention.

[0078] [FIG.10] is a flowchart representing an exemplary embodiment of the enrollment procedure of the present invention.

[0079] [FIG.11] depicts an example for OTV generation based on Token’s timestamp

[0080] FIG 12 depicts three examples of a Token cooperating with an application for GEN and CHK operations.

[0081] [FIG.13] is a flowchart representing the use of the architecture in a Token working in tandem with application software running on a mobile device or on a computer that is also used for the messaging itself.

[0082] .

Description of Embodiments

[0083] FIG. 1 is a schematic block diagram of an exemplary embodiment 100 of the invention having an architecture that in a preferred embodiment of this invention would be incorporated in an electronic device hereinafter referred to as “Token” comprising the following major components: a) PWR (power) toggle switch (105) for turning the Token On or Off. This switch is optional (for example, Power ON function could be achieved by any other key or key combination when applied during OFF state and Power OFF could be achieved by automatic turn off after predefined null time) b) A user Data Output means being a display (110) with a few lines of alphanumeric display. c) User Data Input is a Keypad (120) for data entry. d) Functional pushbuttons (FNC) (130), containing CFG (1310) GEN (1320) and CHK (1330). e) RST (140) is an input means for executing a first built in firmware (Loader) for enabling various recovery operations. f) BAT (190) being a powering means (note: a battery-free device may be considered when power arrives from external sources such as via NFC) g) A Storage means, memory (170) h) CPU (160) that interfaces with the different types of components contained in the Token. (100) i) OTV module (195) as discussed thoroughly above.

[0084] In an embodiment of the present invention, the input means (140) is an internal pushbutton that can be reached via a small hole in the cover using a pin. It could as well be replaced by a virtual function such as turning the Token ON while a specific functional pushbutton (or subset of functional pushbuttons) is pressed.

[0085] The user inputs of the present invention can be, but not limited to, any combination of switches, keyboard, keypad, touch sensors, touch screen, voice activation, biometrics sensors, etc.

[0086] The user outputs of the present invention can be, but not limited to, any combination of LED display, e-paper display, LCD display, voice messaging, etc.

[0087] Other optional components of the electronic device of the present invention include: a) BIO (150) a biometric sensor for scanning fingerprints, detecting facial patterns, specific gestures, etc. This sensor is used to enable operation of the Token without the need to manually insert a password thereby providing a high level of security and convenience. b) PAIR (145) a key for supporting the operation of the Token via very short range wireless communication (such as short range Bluetooth or NFC) or via wired digital interface with another Token or with a messaging system device (such as a cell phone or a PC) and c) (DIG) (180) a digital interface (either wired or short-range wireless). d) The powering means BAT (190) can be regular, rechargeable or an external power source. e) Tamper detector(s) (175) an optional physical security module(s) further described hereinafter.

[0088] In an embodiment of the present invention, the powering means is rechargeable, the Token is provided with a charging interface (to a charger) (CHRG) (185). A non-rechargeable, non-replaceable battery provides an advantage, in that the battery is not required to be charged time and again and when required the Token as a whole can be replaced thus avoiding any tampering with the internal working of the Token, for example the setup of date and time.

[0089] The memory (170) of the Token (100) of the present invention, is provided with different blocks of memory functioning for loading and storing information and various functional modules which can be called for, required for proper functioning the Token as will be described in the proceeding paragraphs. a) The memory (170) of the Token (100) comprises of: b) The ROM /LDR memory (1710); c) The program memory PRG (1720); d) The RAM (1730); e) The persistent read and write memory CRPT (e.g. FRAM) (1740); f) A buffer memory BUF (1760); and g) An additional memory LOG (1770).

[0090] Each of the said memory modules has their particular function during the operation of the Token and will be described in detail. In other embodiments an additional ROM is included with production stored values such as manufacturer’s public key (e.g. for authenticating new software version) and a S/N (e.g. verifying User-ID uniqueness per Token). All types of memory except for BUF and LOG are accessible only to the internal system’s processor. BUF and LOG are dual port memories that can be accessed also by external device as described hereinafter.

[0091] In preferred embodiments of the present invention the architecture of the system is embodied in a dedicated stand-alone Token, yet the same architecture could be applied to other hardware devices either dedicated or not. [0092] The Token (100) constructed according to the architecture of the present invention will be an off the shelf device not pre-dedicated to a specific user or group of users. And not limited to any specific standard and will contain the CRPT memory (1740) which is a persistent read/write memory (e.g., FRAM) that holds various security data such as, but not limited to, the user’s password, User ID, Group Key, list of received OTV’s per group/user, last Token’s timestamp, biometric template (if used), Token provider’s public key (if software upgrade is supported), number of password retries, last generated User-ID (if PAIR’S master also generates User-IDs), Potentially all current group members, per group, Currently active buffer (if double buffer software upgrade is supported), Token’s encryption keys (if PAIR enrollment uses encryption, master could store other Tokens’ public keys but it is not necessary), new software version ready and system serial number (provider’s public key and system serial number may be stored in a different memory type).

[0093] In a favored embodiment of the invention all sorts of memory (except BUF, LOG) is accessible only to the CPU of the Token. This is enforced by hardware. In the case that the Token interfaces with other external sources, a separate buffer memory (BUF) (1760) is provided that is accessed both by the CPU and by the other party connected to the Token with hardware enforced read/write privileges.

[0094] The CPU (160) of the Token interfaces with all types of memory (170) contained in the Token (100). Upon startup the CPU first runs the Loader program located in a ROM, EPROM or any other type of firmware denoted LDR (1710).

[0095] In case of a normal startup the Loader may perform some diagnostics and then transfer control to the program memory - PRG (1720). If the Token runs the Loader during RST operation then it will provide the user the option to reset the Token to factory settings or if software upgrade is supported with dual version storage an option to switch between versions. The PRG holds the main program of the Token in a persistent read only or, in the case that software upgrade is supported (an optional feature to be discussed below) in a persistent read and write memory (e.g., FRAM). In the case of software upgrade support the PRG may be built in double buffer structure enabling to hold two program versions with a flag determining which version is currently active and will get the control from the loader. This mechanism is optional and allows for smooth software upgrade and version fold back if required. (In such a case the version switch function (needed both for upgrade or fold-back) will be added to the LDR procedure to be selectable when LDR runs during RST).

[0096] The CPU runs the software directly from PRG and uses RAM type memory (1730) as data pad for its data manipulations and for buffering messages in the case where Token communication is implemented.

[0097] In an embodiment of the invention, a logging feature is provided wherein events in the Token, such as authentication actions, or OTAC generation actions, or time setup, are written as records to a persistent memory. In such a case an additional memory (LOG) (1770) is used which is read-only accessible to an external reader. These are explained in detail in the below paragraphs.

[0098] The CRPT memory (1740) may be secured persistent storage i.e. , secured physically (there is no need to secure it electronically since it is not accessible by hardware to external devices). An example of physical security of the secure persistent storage may correspond to detection of physical tampering of the secure persistent storage by the optional tamper detector(s) (175). Depending on the type of tamper detection implemented by the Token, the Token may include one or more tamper detectors. When any of the abovementioned tamper detectors detect a tampering attempt they can shred the CRPT content or damage it so it cannot be read.

[0099] Unlike the usual cases where such measures are taken (i.e. to prevent a thief from achieving critical data) the case here is different since there is no critical data in the Token other than the Group Key (and the Token’s private key if PAIR enrollment with encryption is implemented) which becomes useless as the Token is detected as missing by its owner). The main reason, therefore, for including such measures in this invention is only for the case where the owner herself is trying to reverse engineer the Token for insurance scam reasons. This issue is explained in more details elsewhere). [0100] FIG 2 depicts the architecture’s main operating program. The control is transfer to the main program (205) from the loader procedure explained above (detailed explanation of the loader procedure is in FIG 8). Basically, the Token should provide the user with the following basic functionalities: GEN (create OTAC per message sending operation), CFIK (authenticate each message received) and CFG (allowing the user to perform some configuration at will). Flowever the Token must first be initialized and also must verify its own user to be able to provide this functionality. The main program first tests the Token condition and authenticates the user (some functions, like CFIK, do not require user authentication since any person may be allowed to perform them and hence personalization authentication can be regarded as optional for this operation), and then allows the functionality. The first thing the Token tests is the first required initialization which is the personalization of the Token (210). If the Token is not personalized it calls the “Personalize Token” procedure (215), explained in details hereinafter, before returning to Main Loop [265], After the Token is personalized it authenticates the user according to that personalization. Initially the user can be authenticated only via password entry. However, later on, the user can setup an optional biometric sensor for her authentication. The main program checks whether biometric sensor was setup (220) and if so tries to authenticate the user using this sensor (225). If the biometric verification passed (230) the main program continues to the next step of testing whether the Token had the second initialization - enrollment (260). If the biometric authentication fails the Token displays a notification about it (235) and folds back to test the password. This also happens if the biometric sensor was not setup in the previous stage. To authenticate the user via password the Token performs an “Enter password procedure” (245). If the procedures returns an OK password value (250) (i.e. , the value is identical to the user’s password as was set in the personalization procedure) the user is authenticated and the Token proceeds to the Token enrollment test. Otherwise the user is not authenticated and a proper message is displayed (255) to whoever uses the Token and returns to Main.

[0101] The next testing step of the Token is whether the Token is enrolled. The meaning of enrollment is actually being part of a specific group, which also means has received the group shared secret key, herein denoted “Group Key”. If the Token is not enrolled it is sent by main to the enrollment procedure (262), explained in detail hereinafter. If the Token is enrolled the main program enters the main loop (265) where the Token awaits a function selection and transfers control to the relevant function procedure. The main loop starts with the Token displaying a select message to the user showing the selection options, which here is the functions as labeled on the various function keys (267). The Token then waits for a user FNC key (270). When a FNC key arrives, the Token checks which function key was pressed and acts accordingly. If the CFG key was pressed (275) then the main loop will call the CFG procedure (280) explained in detail below. If the user pressed the GEN function key (285) then the main loop will call the GEN procedure (290) explained in detail below. If the user pressed the CFIK key (in this example the remaining option then the main loop will call the CFIK procedure (295) explained in detail below.

[0102] FIG 3 depicts the Token’s CFG procedure that provides the user with a few configuration operations. These operations are usually performed once or very rarely and are aimed at changing the user password, or setup the optional biometric sensor, or optionally upgrade the Token software or optionally PAIR the Token with another one for the optional enrollment procedure that may be performed in an implementation that supports Token communication.

[0103] When CFG takes control (301) it first displays to the user the configuration options and requests her selection (302). The Token then waits for any options selection or for a CLR press that would symbol the user wish to exit the CFG procedure (303). If the selection made is “Change password” (304) then the Token activates the Enter “new password” procedure (306). If the returned value is a valid new password (308) then it is assigned to a Temp variable (309) and the Token activates the Enter “new password again” (or “confirm password”) procedure (310). If the return value is identical to the value stored in the Temp variable (312) then the replacing password operation succeeds and the Token assigns the new value to password (314). The Token notifies the user about the success of the operation (316) and returns to the main loop. If the new password value could not be validated or the repeated entry does not match the first entry then the Token notifies the user about the operation failure (313) and returns to the main loop (395). [0104] If the user chooses a different configuration operation such as setting up Bio (i.e. setting up the biometric template) (318) then the Token requests the user to provide his biometrics to the sensor for the creation of the biometric template (320). In the example implementation here, we assume a fingerprint sensor, (in an embodiment of the invention it is also possible to integrate the fingerprint sensor with the power ON button such that if the biometric template is setup then powering the Token already authenticates the user). The biometric sensor then samples the biometric input provided by the user and checks whether the sample is valid. Valid sample means that the information in the sensor is rich and clear enough to create a stable template. If the sample is not valid (322) the Token notifies it to the user and allows her to try again (324). If the sample is valid the Token builds a template out of it (326). Further sensor operation will take the new samples, turn them to measured templates and compare them with the stored template. If a measured template is similar (there is a threshold for this) to the stored template then the user is authenticated. Before this function is usable it is common to make a test. Since the biometric attempt is not absolute as a password, the test gets a few retries (N). The “retries” counter is initiated (328) and then the Token requests the user to “touch” (i.e. provide her biometrics to) the sensor (330). If the measured template is not similar to the stored template (332) then the Token notifies the failure to the user and ask for a retry (334). Then the Token increments the counter (338) and checks whether all retries have been used (338). If not then there is another measurement. If there are no more retries left the Token will assume that the stored template was not successful, notify that to the user (340) and let the user repeat the setup procedure form its beginning. If the test succeeded the Token will register the stored template in persistent memory (CRPT) (342) and return to the main loop.

[0105] If the user chooses none of the configuration options the remaining option is that the user clicked the CLR key (318) which immediately ends the procedure.

[0106] FIG 4 describes the basic usage of the invention as an example. In this example assumption is made that the CEO of a company intends to send a message (e.g. via his email or other messaging system) to the CFO with instructions to perform a wire transfer of a certain amount to a specific bank account. Since this is the common scenario for these parties, they agree in advance on the following: The CEO User’s ID = 1 and the CFO’s User ID = 2 (although the latter is not necessary for FIG 4 purposes). They also agree that they want to protect two data items that will be inside the message: The first data item is the amount to be transferred and the second are the 4 least significant digits of the bank account being the target of the funds’ transfer.

[0107] The operation is first performed by the CEO who prepares the message, protects and sends it, and then the operation of the CFO who receives the message and authenticates it.

[0108] The CEO operation starts with writing the message in her email (410). Then before sending it, the CEO activates her Token, enters her password or biometrics, and selects the GEN operation which is used by the Token to create the OTAC (420). The Token provides the CEO with the option to add data items to it before the OTAC is generated. As agreed between the CEO and the CFO the CEO enters two data items, the amount (in this case 130000) and the 4 least significant digits of the target bank account (in this case 6789). Then the CEO presses <Enter> and waits for the OTAC values to appear on the Token’s display. The Token generates the OTAC using an internal OTV (One Time Value), the User-ID and the data items. There are several implementation options to create an OTV - one of which is the current date/Time. The Token then displays to the CEO the generated OTAC and the OTV that was used to create it (430). The CEO enters these two values to the message (440) and sends it. The CEO signals the Token that the operation ended by clicking any Token key.

[0109] The CFO operation starts when she receives the message in her email (460). The message should include the OTAC and OTV in the agreed location. If not it is not authentic. If there are two such values in the message they can be used to authenticate the message (in specific the sender and the two protected data items). The CFO uses her Token to perform the authentication. She starts it, enters her password or biometrics, and selects the CFIK operation. Then she inserts to the Token the expected User ID of the sender (in this case 1 ), the received OTAC and OTV and the data items received in the message as agreed (470). The Token calculates the OTAC that the sender’s Token should have created but does not display it (480). Rather it compares it to the received OTAC and if they are equal provides a “PASS” indication, meaning the authentication succeeded. If the calculated OTAC is not equal to the received OTAC then the Token will display FAIL meaning the authentication failed. Then the CFO signals to her Token that the operation ended by clicking any key (490).

[0110] FIG 5 (500) depicts the GEN function which was depicted in high level in the description of the example in FIG 4, for the sender side. A group member wishing to send an authenticate-able message to another member in his group should first write the message in any tool and then operate the GEN function in the Token (505). First the Token generates an OTV (540), in this example, just retrieving the Token’s timestamp. Then the variable D is initialized by assigning to it the OTV value (507). Other methods to generate OTV will be discussed below (mainly for addressing the situation in which a group member might try to generate a fake message). Then the user gets the option to enter some data items from the message into the Token to be used if the sender wishes to make these data items authenticate-able as well. This should be done if there is a worry for a man-in-the- middle attack whereas the hacker will change only data within the message that if this data was not protected will pass the sender’s authentication but will have unwanted consequences (like sending the money to the hacker’s account). The Token asks the user to either enter the data items or continue (no more data items to protect) (510). If the user selects to protect a data item (515) then the Token lets the user enter the data item to be protected (520). If the value seems OK (in case there are rules to be applied for such data) (525) then the data item is appended to the string D (530) and the user gets to enter an additional data item or to continue with the GEN process. The appending to D operation may be any type of operation such as string concatenation, simple integer addition (after values are converted to integers), etc. as long it is the same algorithm as will be performed in the CHK operation, the result is acceptable by the OTAC generation algorithm (e.g., as a counter value in HOTP) and is practically unique to the OTV and data items inserted (i.e. if a data item is modified the result will be different). If a data item inserted is not OK then the user is notifies (585) and the procedure ends (returns to main loop) (595). It should be emphasized that the data items protected need to be within the message and the receiver needs to know which data items are protected and use them as well for the authentication process. After the user selects to continue, the variable T is constructed by appending the User-ID of the Token’s user to D (550) (following the same appending method as before). The creates variable now holds the value to be used together with the Group Key to generate the OTAC. At this stage the OTAC is generated (560). In this example the standard method of HOTP is demonstrated, where T replaces the counter of HOTP and we selected the default OTAC length of 6 digits for the truncation operation. The generated OTAC value and the Last OTV value are displayed to the user along with the instruction to press any key when ready (570). The user is expected to first type the displayed OTAC and OTV into the message and then the message can be sent. After this data was used, the user can press any key in the Token to signal the data was used and the operation can be terminated. When the Token detects a key press (580) it will exit the procedure.

[0111] FIG 6 depicts the CHK function - i.e. the operation a message receiver should perform to authenticate the message. The CHK operation starts (605) after the message from the group member has been received. The user needs to verify that the message contains the OTAC and its OTV that should have been created by the sender and if the sender protected data items the user should be able to identify them in the message body. This can be based on predetermined agreement regarding which data items should be protected and in which order all this info can be included explicitly in the message (e.g. by bolding them, or repeating them in the message bottom together with the OTAC and the OTV, etc.). At that point the user enters the OTAC from the message to the Token (610), if the value entry is not successful (615) the Token displays a “Fail, click <Enter> to exit” message (690) and after clicking <Enter> the procedure ends (699). If the value entry was successful the Token assigns the value to the received OTAC variable for later use (617). Then the user is requested to enter the OTV that appears in the message (620). If not successful (625) then the user is notified and sent to exit as before. If the entry succeeded then the value entered is assigned to the received OTV variable (627).. At this stage the variable D is initialized, by being assigned with the value of the received OTV (630). Then the user is requested to select whether to enter a data item to be protected or to click <Enter> to continue with the CHK operation (632). If the user selected to add a data item (635) she is requested to enter the first/next data item. If the entry is not successful the user is notified and sent to exit as before (645). If the entry is successful it is appended to the D variable (650) and this process repeats for all data items to be protected. The appending method should follow the same method as used in the GEN function. The procedure continues in one of two ways, depending whether the expected sender User-ID is required of the user or the Token is supposed to check for every potential sender. The second way has the pro that the user need not execute an additional entry, but has the con that the Token is required to know all potential senders’ User-ID’s and try them all. Therefor the second way fits mainly for small groups with a bounded User-ID value. The actual implementation may have only one of these ways implemented. For the purpose of explanation FIG 6 depicts both ways as if there is a decision step (637). If the user is required to insert the expected sender’s User-ID she is requested by the Token to insert it (655). If the entry is not successful then the user is notified and sent to exit as before (660), otherwise the entered value is assigned to the variable U (665). If the selected way is for the Token to try potential senders it assigns the USER-ID of the first potential sender to U. This value is the smallest from the set of all USER-ID’s active in the group excluding the User-ID of the user herself. Then the variable T is constructed by appending the U value to the D value. This operation should follow the same principle as described above for the construction of D. At this stage the OTAC can be verified using the Group Key and the T variable (675). The generated OTAC is then compared to the received OTAC (680). If the generated and received OTAC are not equal then it could be that the sender’s User-ID inserted to U is not the correct one. If the Token is working in the mode of trying all User-ID’s then the next potential User-ID should be tried. Of course if all User-ID’s have been tried which is inherently the case if U was entered by the user it means that this is the only User-ID to check and so it means there are no other User-ID’s to check then the user is notified and sent to exit as before (681 ). If however, not all potential User- ID’s where checked then the Token assigns the next User-ID to U (683) and reconstruct T (673). If for one of the tried User-ID the calculated OTAC and received OTAC equal then the message is probably authentic but it could still be fake (e.g., a recording of an authentic message). To verify the message is not fake and allow next checked messages to be verified for this attack as well the OTV verification is performed. First the Token checks if the received OTV is already stored at R(U) (685). R(U) is an array of structures, one per User-ID of all other Tokens that resides in the persistent memory of the Token and may be updated during a CHK operation for the checked User-ID structure. The structure may be a single integer (i.e. the last received OTV) but this is limiting in 2 aspects: a) messages must be checked in the same order they were created and b) messages cannot be re-checked at a later time against being a recording of a valid message. Therefor the structure is likely to be one that can hold multiple OTV values. One way is to create a dynamic structure where values can be added indefinitely. This has the disadvantage of not knowing in advance how much memory is going to be needed and there is the risk of going out of memory. A more practical structure would be one with a predefined limited number of entries (whether an array or stack or linked-list, etc.). Limiting the number of entries means that “older” OTV’s from that User-ID will sometimes be removed from the structure, which means that messages of that removed OTV or older OTV’s are rendered irrelevant. If the number of structure entries is large enough it should not be regarded as a practical limitation (if a request to wire transfer money was not read while already a certain amount of later messages were read it is considered not relevant anymore). If the received OTV is found in R(U) then the message was already tested before. In this case the user is displayed with the “Pass but already checked before” followed by “click <Enter> to exit” (689). This means that the checked should not be treated as a new one and therefore a recorded valid message will not cause problems. Also, this is usually the message expected when a message is being re-checked at a later time (perhaps by a third party). If the received OTV is not found in R(U) then it is either a new message or an “old” OTV that was at some point removed from r(U) because it was the oldest OTV in a full R(U) when a new OTV has been received. Hence. At this stage R(U) is checked for fullness (686). If r(U) is not full then the received OTV is new and is inserted into the R(U) (682), followed by the Token displaying “Pass” followed by “click <Enter> to exit” (684). This means that the message is new and authentic. In the case of letting the Token detect the sender’s User-ID automatically, the Token may add the detected Sender’s User- ID to the Pass message so the user checking the message can be sure of who sent it. If the R(U) fullness check detected that it is full then the received OTV is compared to the value of the oldest OTV value in R(U) (687). If newer then it means that it was not previously removed from R(U) and hence should be considered as a new value. In such a case the oldest entry is removed from R(U) (688) and the received OTV is inserted to R(U) (682), and as before followed by the Pass message. If however the received OTV is older than the oldest entry in R(U) then it cannot be considered a new value since it either was already tested and at some time later removed from R(U) or it is older than the number of messages that are considered relevant (i.e. belongs to an irrelevant message) and so cannot be authenticated. In this case the user is notified about the Fail result and sent to exit as in the previous cases of this notification.

[0112] In

[0113] FIG 7 depicts an example of data entry (“Enter <value name>”) procedure (705) which starts with the Token displaying the <value name> entry request to the user (710). The procedure returns to the caller procedure a result named “Value”. Value is initiated to -1 (712) and if a proper value is provided by the user Value will be assigned that value. Each such procedure may have a count definition that defines the number of retries the user can do in her effort to enter the value. This count is initialized to 0 (713). Then the Token initializes a string variable and begins to collect the characters arriving from the user data input (in our example - keypad with 10 digits, CLR and <Enter>). Whenever a character is received (715) it is tested whether it is the “Enter” character (720) that is used by the user to signal the end of the value entry operation. If not then it is tested whether it is the CLR character (725) that is used by the user to signal that she made an entry mistake and wishes to erase the string created so far (730) and start a new one. Note that this is a minimal implementation as related to the user’s ability to edit the value entered. In some embodiment different implementation could also provide keys such as cursor movements or backspace, etc. A preferred embodiment of the invention may reduce number of keys in a very limited space which may lead to better usability. Any other char is first validated (727) if required by the specific value’s rules (e.g., if the value relates to a password then only certain characters are permitted). If a character is not validated then the Token will display this fact to the user (e.g., by blinking the display a few times) (726) and will wait for another character. If the character is validated it is appended to the string entered so far and echoed to the user (728). When the “Enter” character is received the string is validated if needed by the rules of the specific value (735) (for example the value’s string length must be within some bounds). If the value is OK then the Value return variable is set to the entered string (755) and the procedure exits (795). If the string fails validation then the Value remains the initial value of -1. The Token then increments the counter (740) and compare its value with the parameter N which defines the number of permitted retries for this value entry (745). Note that if N==1 then it means only one trial since after the first failure the comparison will be TRUE and the procedure will end (returning the Value -1 meaning Failure). If N is larger than 1 then the user gets a message to try again (750). If none of the retries succeeds then the procedure ends with return value of -1 . Note that in N==0 means infinite retries since the comparison between the counter and N will always yield “No”.

[0114] In an embodiment of the present invention for certain types of values such as passwords the “^*” character (or some other predefined one) will be echoed to the display instead of the actual character entered. In an embodiment of the invention for certain types of values such passwords, when all retries had failed the Token may get completely blocked and to use it will require a RST procedure and then re-personalization and re-enrollment procedures. In this embodiment the number of retries is saved into persistent memory (e.g. CRPT) so even if the entry is retried after powering off the device the number of retries will start not from 0 as in (713) but instead from the number retrieved from the memory and will accumulate and the retries counter will only be reset after a successful entry. In an embodiment of this invention the data entry procedure may include a time-out timer that is activated at specific steps to limit the time giver to the user to do an operation. If the timer times out before the operation was performed the user gets a “time out” message and the procedure exits.

[0115] When the Token is powered on it starts to execute the Loader program that resides in LDR memory (1710). The LDR procedure (805) checks whether the RST key (140) is pressed (810) and if it is not (the normal case) it transfers the control to the main program (895, 205). Optionally it may perform also some diagnostics of the Token. If the RST key is pressed during the LDR procedure then the Token allows performing some recovery-based functions.

[0116] FIG 8 demonstrates the Loader procedure of the present invention such as resetting the Token to factory settings. In this example the Token displays a Warning message to the user relating to the fact that performing reset to factory settings will erase all user and group related data. The user is requested to press a specific key (in this example the RST key again) to approve the reset or any other key to abort (830). The Token waits for the user response (840). If it was any other key then RST it will display “Operation aborted” (860) and transfer control to the main program. If it was RST then the Token will reset itself to factory settings (880), display this fact (890) and transfer control to the main program.

[0117] FIG 9 depicts the personalization procedure that was mentioned in FIG 2 explanation and must be performed before any other main loop procedure can be operated. The personalization is basically the configuration of both the User ID and password to the Token. Note that the User-ID must be unique in the group and its entry could alternatively be done within the enrollment procedure which, especially if user PAIR mechanism, may provide better ways to verify User-ID uniqueness in a specific group as further detailed below.

[0118] After the procedure starts (905) it requests a User ID entry procedure (910). If the entry fails (915) then the user is notified and the procedure exits. This is also true for any next data entry by the user. If the entry succeeded then its value is assigned to the User ID variable in persistent memory. The next data entry is the password (925) which value if valid (930) is assigned to a temp variable (935). The next data entry is of the same password again (940). If value equals the Temp variable value it means that the second entry is identical to the first (945) and the value is assigned to the password variable in persistent memory. In our example implementation the Token then displays a OK notification to the user (960) and exits.

[0119] FIG 10 depicts an example of the enrollment procedure which is manual. As seen in FIG 2 explanation above, before getting to use the procedures of the main loop (GEN, CHK, CFG) the Token must be enrolled. As personalization creates a relation between the Token and a specific user, enrollment creates a relation between the Token and the group. In other word - providing the Token with the shared secret of the Group denoted Group Key and optionally the User-ID if performed in the enrollment procedure rather the personalization procedure which is not the case in the FIG 10 example.

[0120] In a preferred embodiment of the invention this procedure is to be carried out by a different user than the user to be use the Token (Admin). The procedure (1005) starts with a data entry procedure of the Group Key. The admin who knows this group key needs to get a target Token after it is already powered up and authenticated and perform the Group Key entry (1010). If the Value entered is not valid (1020) the Token displays a fail message (1025) and exits. If the value is valid it is assigned to the Group Key variable in persistent memory. Then the Token displays that it is enrolled and exits the procedure. Note: sending a test message after being enrolled can verify the correctness of the Group Key entered.

[0121] In an embodiment of the invention the Group Key is not inserted manually but via a PAIR mechanism where the Group Key can be automatically generated by one Token (master) and then transferred to other Tokens via either direct communication with them or through a mediation device. This mechanism is further explained hereinafter. The further explanation also addresses the case where PAIR is used to provide User-IDs along with the Group Key.

[0122] FIG 11 describes both the Token’s timestamp background procedure (1110) that is used to periodically store the current timestamp in the persistent memory (the CRPT in this example) and the procedure for generating an OTV for the purpose of OTAC generation (1150).

[0123] The background procedure is activated by the RTC (Real-time-clock) which is an element that continuously counts time from some initial value. The initial value can be set during the manufacturing phase or during the personalization or the enrollment procedures.

[0124] Upon a periodic interrupt from the RTC the program performs context switching to the interrupt routine that basically reads the current RTC value (1117) and stores it in the timestamp variable in the persistent memory (1119). Then the interrupt routine switched back to the program which continues normally (1120).

[0125] To generate an OTV for the purpose of OTAC generation the OTV generation procedure first reads the current timestamp from the RTC (1155) and initializes the OTV to that value (1160). Then the procedure reads the timestamp from the CRPT (1170) in order to verify the OTV is larger than it 1175). If this is the case then the procedure updates the CRPT timestamp to the OTV value (1185) and returns to caller (1195) with the OTV value. If not (can happen due to RTC reset e.g., during battery exchange), then the OTV is taken from the CRPT timestamp (1180) and the RTC is updated as well (1190) and then the procedure returns to the caller with the OTV value.

[0126] FIG12 (1200) depicts an embodiment of the invention comprising the use of a Token and application software installed in a device (e.g. smartphone, PC, etc.). Unlike previously described Token and device cooperation relating to various Token management operations such as “PAIR” via a device acting as a mediation device, or checking logs or upgrading software this embodiment relates to cooperation for the basic functions of the system: GEN and CHK. Such an application is denoted here “OTAC App”. As previously such cooperation requires Token to device communication (whether wired such as USB or wireless such as Bluetooth or NFC, and the same methods of preventing malware entry to the Token apply here as well. There are multiple ways of Token and application cooperation for GEN and CFIK. Three such cooperation examples are depicted in the figure. FIG 12a describes a case where the OTAC App (1240) is just serving as a more convenient user input used to command or enter data items into the Token (1220) that is usually a small device with limited space and power to accommodate full keyboards, etc. In this case, for GEN operation, the user (1210) writes her message in any messaging media she chooses (e.g., messaging application, email, phone call, paper-letter, etc.) (1270). then activate the OTAC App and the Token and choosing the GEN function in the OTAC App, along with entering all the data items required. These are then transferred from the OTAC App to the Token via the Token-to-device communication. The Token calculates the OTV and OTAC, while showing the data on its display to the User. If the data presented to the user is aligned with the data, she entered into the OTAC App then she would enter these values to the message and send it. The OTAC App advantage in this case is just the ease of user input. The disadvantage is that there is the application and necessary Token to device communication required. In the CHK operation, the user, after identifying the data items and the OTAC and OTV, activates the CHK function in the OTAC App, enters the OTAC, OTV and data items (and if required the expected sender’s User-ID) to the OTAC app which transfers them to the Token, which present them to the user on its display as well as providing the PASS/FAIL response. In FIG 12b The OTAC App (1250) is also communicating with the messaging method which must be digital messaging mean such as email, or mobile messaging application, etc., (1280). This method loses the benefit of using any messaging media but has also the advantage that the data to be protected can be taken from the message automatically (i.e. user need not enter it to the OTAC App or Token as well) and also OTAC and OTV are added to the message automatically and hence are not required to be entered by the user and is not required to be “user friendly” (e.g., OTAC truncation is not required). Also, since the data can be taken from the message and does not require re-entry, then its “user-friendliness” becomes relevant only for the display purpose. This specific issue of data display will be discussed in more details below (within the FIG 13 explanation). In GEN operation the user writes the message in the messaging software she uses and that has communication with the OTAC App. Then, either that software or the user activates the OTAC App (depending on implementation - will be further discussed below) and the user activates the Token (1230). Upon selecting the GEN option in the OTAC App, the OTAC communicates with the Messaging software to retrieve the relevant data to protect and send it to the Token with the command to GEN (as mentioned the issue of “relevant data to protect” is further explained in FIG 13 explanation). The Token presents to the user the data it protects so that the user verifies it is the correct data and waits for the user ACK. This ACK is the only user input required in the Token and is required to protect against a malware-initiated message. Upon ACK the Token will send the OTAC and OTV to the messaging software which will then send the message. In CHK operation, upon receiving a message in the messaging software the user (or the messaging software - depending on implementation) activates the OTAC App and the Token, selecting the CHK option in the TOAC App. The OTAC App then retrieves the protected data, the OTAC and the OTV. If the user is required to enter the expected sender’s User-ID then she will do it in the OTAC App or this operation will be carried out by the Token when receiving the data and codes from the OTAC App per each potential sender’s User-ID until a match is found (or the operation fails). The Token presents the data to the user on its display so the user can verify that the data in the message is indeed the data verified (to protect against malware sending to the Token incorrect data). There are various ways to implement FIG 12b. In one embodiment the OTAC App is a separate application and the communication with the messaging software is either by operating system features such as copy/paste, or by using proper API for inter application communication. In another embodiment this can be done by extending a messaging software’s capabilities to include the OTAC App functions (such as writing proper email extension). FIG 12c adds to the OTAC App (1260) the messaging functionality so it is a dedicated application for messaging using the Token (1230) of this invention’s method. FIG 12c is discussed using the example of FIG 13.

[0127] FIG 13 demonstrates via an example the Token with OTAC App as described in FIG 12c above, i.e. , an embodiment of the invention comprising the use of a Token and application software installed in a device (e.g. smartphone, PC, etc.) that cooperates with the Token and is used for messaging of messages authenticable by the method of this invention. In FIG 13a, the user (1320) in this embodiment works with both her device running the app (1310) and a Token (1330). The App is used both for writing, sending, receiving and displaying of messages as well as communicating with the Token for purposes of GEN and CFIK operations. In one embodiment of this invention, which is the one depicted in the FIG 13 example, the App is tailored to a specific message format. I.e. in addition to any “free” text that the user writes it contains predetermined data items that the user must insert to it. These data items are automatically detected and marked as such by the App. For example, The App is tailored to the money transfer request type of message. In this example the App provides the user with two data fields for the user to insert: the amount to transfer and the target bank account. Flence the user just needs to enter the App and inserts these two values and any additional free text and then the message is ready for processing (1). (BTW - actions in FIG 13 are numbered according to their order of execution). The user then activates the Token by selecting the GEN-A function (GEN based on App) (2). The order between actions (1) and (2) is not important. When the user finishes entering the data items to the App she submits the message (3). The App then sends the fields’ values to the Token using the Device to Token communication (1340). The Token receives the data and generates the OTV, and the OTAC, it will be understood that communicating the OTAC by the Token to the application spares the need for truncation step in the OTAC generation. Then the Token displays to the user the data items it was processing with the User-ID, and optionally also the OTV and OTAC it generated. (5). The user can now visually verify that the Token generated the OTAC according to the proper data and User-ID and presses “ACK” (6) to signal the Token to send the OTAC and OTV back to App (7). The user’s “ACK” action is required to make sure that the message is not initiated by malware and the user is aware of this procedure and verified that the proper values were sent to the Token. When the App receives the OTV and the OTAC created by the Token it embeds them in the message and then sends it (8). The App then notifies the user it is done and exits (9). Note that even if the App is infected with malware it cannot do anything that will create a fake message that is going to be authenticated by the receiving Token, other than the correct message and correct OTV, User-ID and OTAC values. At the receiving end a similar activity is performed. This is depicted in FIG 13b. The receiving App (1350) receives the message (1) and displays it (2) to the receiving user (1360). The receiving user operates its Token (1370) and activates the CHK-A (l.e. check related to app embodiment) function (3). The app then sends the data items as well as the received OTV and OTAC from the message to the Token (4) over the Token to app channel (1380). The Token displays the message items and optionally the additional values to the user (5) so the user can visually verify that the Token received for processing the same values as appearing in the message). In parallel to the user examining the data displayed in the Token’s display the Token performs the CHK operation to verify the message. If the user sees wrong values then the message is considered contaminated and the operation resolves as FAIL regardless of the Token verification results. If the user is satisfied that the Token received the proper values, then if the Token displays FAIL the CHK failed and if it displays PASS then the message is authentic (6). (Note: the Token may also display “PASS, was checked before” to notify that this is not the first time the message is checked which protects against attack of recorded message, yet the message be rechecked any number of times (e.g. by a third party wished to verify the message when acted upon was authentic). Also the Token may display the sender’s User-ID (if detected automatically).

[0128] In another embodiment of this invention the messaging application need not be template based or structures in any way. The Sender writes any message and then can mark the words in the message she wants to make authenticable. These marked words are sent to the Token and displayed there so the sender can verify the Token is protecting the right words. Also, the marked words remain marked in the communicated message and are marked as well at the receiving application which also sends them to the Token for validation. And again the user can see these words displayed in the Token in the CHK-A operation and verify that these words are the same as in the message and are authentic. Malware that will try to change any of these words or remove their marks or mark other words will fail the authentication and the receiver will be able to tell that the message is not authentic.

[0129] In another embodiment of this invention the messaging application protects the entire data such that the sender need not mark any words. If the message is very short then the Token will present the entire data for the user to verify the proper data is protected. However, if the message is too long for being displayed on the Token at once then either a different user output is used (such as a text-to-voice function and a speaker/earphone) or it can still be displayed in scrollable manner. Alternatively, still using a display, a way for the Token to “convince” the user that the correct message data was received by it and is being protected without displaying the entire data can be employed. This can be achieved by the App selecting smartly words from the message to display to the user. Smartly in this context means a selection that although performed automatically will provide high confidence that the data fully represent the data in the received message. Such a selection may select words with numbers, known names, names in a predefined dictionary (that may be dynamically updated) and a few random words. Words that hold no significant meaning such as “at”, “in”, “the”, etc. can be ignored. If the user identifies these selected words as belonging to the message and in the right order she can be convinced that the message the Token received is the proper one. Then the Token bases the OTAC on the entire message text. Then at the receiving end the application transfers the entire message to the Token for validation. If the message is short the Token can display the entire message to the user for verification that it is the same as the received message. If the message is long, then the same principles used in the GEN side can be applied in the CHK side. In this scenario the messaging application is free from restrictive structure and the user does not need to mark specific words since the entire text is protected

Examples and embodiments of the invention

[0130] For the OTAC (One Time Authentication Code) generation algorithm, a onetime value (OTV) is used. The OTV function (195) provides this value. In one embodiment of this invention the OTV is implemented by a simple counter based on keeping the last OTV value in persistent memory and increment it when a new OTV is required (and updating the last OTV in the persistent memory. The initialization of the counter (e.g. to 1) should happen in one of the initialization procedures of the Token (e.g., the Personalization or enrollment procedures). In another embodiment the OTV is a local time-stamp (see FIG. 5). In this method the current date-time is entered into the Token in either the manufacturing stage or the personalization or enrollment procedures and it is incremented by the software to provide constant date-time that are used as timestamp for the OTV. Note that the initialization date time setup is not mandatory since it is assumed that there will be proper messages before any attempt to fake a message is tried. In such cases the proper message usually contains correct date and time information attached to them and by adjusting their OTV timestamp to the message’s date and time the correct time of any local time can be inferred. This method has the advantage over the counter method because it makes it impossible to use the Token to create a fake message (by a user that turned malicious) as if originated in the past. This point is further discussed in the advantages of this invention section. While the generated time of day in this method is not very accurate it is accurate enough for its purpose. Note that with a standard crystal (calibrated and temperature compensated as used in wrist watches and other such time keeping circuits) of better than 4ppm accuracy the drift of such a Toke’s timestamp can be lower than about 10 minutes over the period of 5 years. The Token’s timestamp is periodically saved in the persistent memory and hence timestamp reset that may happen if a removeable battery is replaces or a rechargeable battery was fully discharged and some time passed until it is reconnected to a charger will resume from the time before the reset and thus will not allow using a previously used OTV. In another embodiment the time-of day mechanism can be based on continuous accurate source, such as by implementing a GPS receiver. The advantages of this method over the local time-of-day method are that it does not require initialization and it cannot be maliciously or due to power down “slowed”. However, it requires more hardware, more power, and is more costly and so the implementer should perform proper tradeoff analysis. The additional failure point (by inserting an additional hardware) can be mitigated by fold-back from GPS time to local time if GPS receiver fails. In such a case the local time-of-day can be used the entire time and just be periodically updated by the GPS receiver. If GPS receiver fails then the updating just stops. The OTV is sent together with the OTAC and therefore the need for holding or synchronizing the same counter values in their Tokens, by the sender and receiver is not mandatory.

[0131] Token devices are usually simple enough and low cost enough to give up the feature of software upgrade. However, in an embodiment of the present invention, the feature of upgrade of software is supported. In this embodiment the PRG memory should be a persistent read/write memory and a means to upload to it a new version is provided. In this option the Token contains a stored (in ROM accessible only to the Token’s CPU) the manufacturer/software provider public key. A digital interface allows writing the new software version that can be received from the software provider (e.g., by downloading it to a computer from the provider’s site). The computer than can write this software version to a special BUF memory in the Token accessible via some digital interface (either wired such as USB or wireless such as Bluetooth or NFC). The computer cannot write more data than can be contained in the free space of the BUF (can be enforced by hardware), The new version must be digitally signed by the provider’s private key. Then the Token’s CPU can read the BUF and authenticate the version using the provider’s public key. If authenticated the version is copied to internal memory accessible to the Token’s CPU only and set a flag in persistent memory that a new version was uploaded. Then, upon restart of the Token the LDR procedure will check this flag and if a new version is waiting will copy it to the PRG memory before passing control to the main program. Alternatively a double buffer mechanism may be supported. In this embodiment the PRG memory is doubled and two versions can be stored in parallel where one of them is the active one (i.e. the one used by the Token’s CPU to run the software). Then the new version after being uploaded to the BUF as described before, is copied to the non-active PRG. The additional feature in this case is that by commanding RST during LDR, the LDR procedure will provide the user with an option (in addition to the option to return to factory settings) to switch between the stored versions by marking the currently non-active PRG as the active one before transferring control to PRG. This allows software upgrade to a new version as well as folding back to a previous version.

[0132] In some embodiments of the present invention, the OTAC generation includes the Token’s S/N, and all group Tokens contain a list of all group members’ User- IDs and corresponding Tokens’ S/Ns. This ensures User-ID uniqueness and prevents multiple Tokens having the same User-ID. This may be redundant when User-ID is created automatically in PAIR procedure since the enrolling Token will not generate the same User-ID for that group twice (there are more details below).

[0133] In an embodiment of the invention, when the authentication includes the receiver’s identity, the receiver’s User-ID could be used in the OTAC generation. The sender would insert the intendent receiver’s User-ID to Token as a part of the OTAC generation procedure (e.g., by entering the value or pressing a GEN key dedicated to that receiver). This embodiment is to be implemented when the message is sent to either a single receiver or multiple receivers where only one of them is “To” and others are “CC” or “BCC”. In this scenario the intended receiver is not required to enter hers User-ID in the verification procedure, since it is known to the Token. In yet another embodiment the receiver’s User-ID could be used as any other sensitive data included in the message.

[0134] In another embodiment of the present invention, an additional function is integrated with the CFG procedure which is PAIR. This relates to the case where enrolling is done via Token communication. In this embodiment, a specific Token is allotted the Master of the group which enrolls itself by generating the Group Key automatically. Other Tokens pair with the master Token to get their Group Key and these Tokens cannot pair with other non-master Tokens.

[0135] If there’s any suspicion for eavesdropping to the pair procedure it is possible in some optional embodiments that in this process, during personalization or enrollment, a key pair is created specific to the Token. During pairing the master Token first receives the public Key of the target Token and then uses it to encrypt the Group Key and send it to the target Token which then uses its private key to decipher the message. Alternatively, not only the target Token provides its public key to the master but both pairing Tokens exchange their public keys between them which enables the master to digitally sign the Group Key as well as encrypt it and the target Token to authenticate it as well as decipher it. For functioning of the PAIR system, the PAIR function is added to the Token during the enrollment procedure of the target Token and during configuration procedure of the Master Token. In an embodiment of the present invention, the enrollment procedure is also used for providing User-IDs to the Tokens. The benefit of it is that it automatically ensures User-ID uniqueness for the group. In such a case the master is creating its own User-ID which is a predetermined value known to all (e.g., 1). Then upon pairing with a target Token the master will create a User-ID for the target Token and will transfer it together with the Group Key. The master can generate the User- IDs using an always incrementing value where the last value is stored in the master Token’s persistent memory (e.g., CRPT) and is incremented per each new User- ID. Note that the master may store a list of all generated User-ID for a group and may also remove from the list any leaving member’s User-ID, thus making the list contain all current members in the group. This enables various User-ID management aspects, such as reuse of User-ID, updating CHK functions with list of potential senders for relevant CHK methods, etc.

[0136] In an embodiment of the present invention, the Token is equipped with Token to device communication to provide an alternative for manual Group Key insertion. This is achieved by providing an USB interface, Bluetooth or NFC for connecting to a PC, smart phone or other device where the group key is generated by an application software and sent to all group Tokens. Yet it should be noted that preferred embodiments of the present invention will not include the storing or distributing of the Group Key using a device with connectivity other than to the Tokens, since such a device couldn’t provide for a malware free environment.

[0137] In another embodiment, the computers/smart phones are used as mediation devices where one Token generates the Group Key and the computer or smartphone functions as users for reading it from the enrolling Token and sending it to another. In order to avoid the possibility of a malware on the computer/device it is required in those embodiments to have the Group Key encrypted as described in Par. 131.

[0138] As emphasized widely the preferred embodiment of the invention is set the system in a Token. Yet in other embodiments of the present invention, the system could be embedded in other hardware configuration.

[0139] In some embodiments of the present invention, where certain group member requires only some of the functions allowed by the system (e.g., member A is sending messages to member B, but does not receive messages, than member A requires only the GEN function, while member B requires only the CHK function), in such cases the system could be implemented in a plurality of partial Tokens. A partial Token does not have the full Token functionality. In specific, in the above example member A will get a “GEN” Token and member B will get a “CHK” Token.:

[0140] In these embodiments where enrollment is done via pairing, the Master Token may not participate later in group messaging but may be used only for the enrollment operation. Such a Token can be denoted “Enroller” Token. The benefits of having such a Token include:

• Improved security: The Enroller token can be kept in a safe and not be carried by a person who may lose it or it may be stolen. Also, if it is clear that there is no need for more slave Tokens the Enroller Token can be reset.

• Improved Pairing: The Enroller can be made with much larger power source than a slave Token. This can enable pairing operation directly with no need for a mediator (e.g., via NFC). Also, the Ul on such Token can be made much more convenient than the ones a small token can provide.

• Since an Enroller Token is not intended to be used for messages authentication in a group, it can be used to generate multiple groups. Each group has its group ID. This has the benefit to enable party A to work with multiple Parties that may be separated from each other and thus multiple groups are required.

[0141] In some embodiments of the present invention, where a Token holder requires to be a part (member or enroller) of more than one group a Multi-Group Token can be used instead of multiple physical tokens. The concept of a Multi-Group Token will be understood as follows; A Token can be regarded as being made of two parts: the Token’s logic, denoted here a virtual Token, and the physical device that runs this logic, denoted here the Token host. A Token host may be made a multi- Token host, by being able to manage and run multiple virtual Tokens. A virtual token can be any type of token (e.g., master, slave, GEN, CHK, enroller). The Multi- Group Token host needs an additional logical layer, dedicated memory space and Ul for managing the virtual tokens, each with its parameters such as Group ID, OTV, etc.. Some Token parameters can be shared by all virtual Tokens in a host, which both simplify the virtual Tokens and the user operations, such as token timestamp, Token personalization, etc. The additional logic layer may manage the multiple virtual tokens, with operations such as: Add Virtual Token, Remove Virtual Token, Select Virtual Token, Extent Virtual Token (if a virtual Token has the expiration date feature).

Claims

Claims

[Claim 1 ] A System for peer to peer authenticating a message, sent within at least one defined group of users, the system comprising: an input means, an output means,

At least one memory or storage components, a processor, a One-time Authentication Code (OTAC) generating module, a OTAC verification module, wherein the said OTAC generating module generates OTAC based on shared secret key (Group Key), and an one-time value (OTV), and wherein said OTV is a unique value per OTAC generation, generated by said system, wherein all systems within said defined group share the same group key, and wherein said OTAC verification module allows verification of OTAC generated within said defined group, and wherein in said OTAC generating module, said output means allows providing said OTV and OTAC, and wherein said OTAC and OTV are incorporated into the message, and wherein in said OTAC verification module said input means allows providing the system with said OTAC, and said OTV. And wherein said output means indicates authentication success or failure.

And wherein said OTAC verification module enables to verify an OTAC limitless number of times.

[Claim 2] The system of claim 1 , wherein the system is incorporated in at least one Token.

[Claim 3] The system of claims 1 and 2 wherein said OTAC generating module further uses at least one verifiable detail of the message, and

Wherein said verification module uses the same at least one verifiable detail of the message.

[Claim 4] The system of any of claims 1 -3 wherein said OTV is based on a source selected from: a counter, a sequence generator, a GPS receiver, an internal software or hardware clock, a pseudo randomizer, or any combination thereof, and wherein said source could be alphanumeric or a time stamp and wherein said time stamp could be a real-world time or the system internal time.

[Claim 5] The system of Claims 1-4 wherein said at least one verifiable detail is the Identity of the user generating the OTAC, the Identity of the user verifying the OTAC, a data item from the message or any combination thereof.

[Claim 6] The system of claims 1- 5 wherein the system is assignable to one user within said group of users.

[Claim 7] The system of claim 6, wherein, said OTAC generating module automatically uses the user ID of the user whose system generates the OTAC.

[Claim 8] The system of claim 6, wherein, said OTAC verifying module automatically uses the User-ID of the user whose system verifies the OTAC, the User-ID of the user generated the OTAC or both.

[Claim 9] The system of claim 6 wherein the system operation requires the authentication of the user it is assigned to.

[Claim 10] The system of any of the claims 1 -9 having a limited connectivity.

[Claim 11] The system of claim 10 wherein said limited connectivity is selected from: wired, wireless and short-range wireless;

[Claim 12] The system of claim 10 wherein said connectivity is designed to be used for: group enrollment, user assignment, system upgrade, log reading or any combination thereof.

[Claim 13] The system of claim 10 wherein the system is a master system, and wherein other systems within said defined group PAIR to said master system to perform the PAIR procedure.

[Claim 14] The system of claim 10 wherein the PAIR procedure uses encryption.

[Claim 15] The systems of any of the previous claims wherein said at least one memory or storage component is selected from: LDR memory, PRG, RAM, CRPT, BUF, LOG, manufacturer’s data or any combination thereof.

[Claim 16] The system of claim 10 wherein said limited connectivity is used to communicate with a dedicated application.

[Claim 17] The system of claim 16 wherein said dedicated application allows to transfer data to and from the system, wherein said data are used by said OTAC generating module or said OTAC verifying module, and

Wherein said data is selected from, said OTAC said OTV, said verifiable detail of the message or any combination thereof, and

Wherein the system prompt said data to the user and allows user control of the authentication.

[Claim 18] The system of any of the previous claims wherein the system includes a tamper detection module.

[Claim 19] The system of claim 18 wherein said tamper detection module erases selected memory types upon detecting a tamper attempt

[Claim 20] A method for authenticating a massage sent within at least one defined group of users, the method comprising:

A sending user

At least one receiving user

An OTAC

A message

Wherein said sending user generates said OTAC, and Wherein said at least one receiving user verify said OTAC, and

Wherein said OTAC is generated by using: shared secret key (Group Key), and an onetime value (OTV), and

Wherein said sending user incorporate said OTAC and OTV in the message to be authenticated, and

Wherein said OTAC is verified using the Group Key and said OTV, and

Wherein said OTAC verification can be made limitless times.

[Claim 21] The method of claim 20 where in said OTAC is generated by further using at least one verifiable detail of the message.

[Claim 22] The method of claims 20 and 21 wherein said at least one verifiable detail of the message is selected from Sender User-ID, receiver User- ID, a data item from the message or combination thereof.