Epinsafe- enhancedpinsafe

Abstract

Extending on PINSafe, described as: "Secure identification of a user in an electronic communications environment, wherein a host computer communicates with a plurality of electronic devices operated by the user. The user is issued a user code, known only to the user and stored in the host computer. User identification involves the host computer generating a pseudo-random security string and applying the user code to the pseudo-random security string to generate a transaction code. The host computer also transmits the pseudo-random security string to one of the electronic devices which displays the pseudo-random security string to the user. The user generates the transaction code by applying their known user code to the displayed pseudo random security String. The user generated transaction code is entered into an electronic device, then transmitted back to the host computer. Positive identification is achieved when the host computer's determined transaction code matches the user generated transaction code." PINSafe, now acquired by us, suffers from 6 flaws (some quite fundamental): 1 - Conceptual flaw - No offline support without caching (leaving the on-demand string lifetime out of the security equation) 2 - Implementation flaw - Trust in transport encryption - HTTPS is easily hackable and interceptable, The PIN generated code can't, as such, be transferred back to the server securely. A bad actor could use the string request URL to grab a valid TURing Image with the initially generated security string, and then cross it with the reply data on the form, capturing, not only the username, the password and the OTC that can easily be reversed back into a PIN, compromising the entire system. 3 - Implementation flaw - Storing of PINs with reversible encryption, due to a clumsy approach to the legacy systems User&Password, 2 field only, authentication realm. 4 - Conceptual flaw - Humans are not to be trusted with secret keeping. Although PINSafe is designed to ensure "one is who one claims to be", and it clearly performs its job, this is conceptually naive as human beings are known to share PINS in efforts to fool the system even when this promiscuous behaviour could render them in trouble… truth is, they fail to foresee complications until they materialise. 5 - Conceptual flaw - One point verification / validation design. In PINSafe design, the server generates the strings and the user, presented with the strings, uses its PIN to extract the OTC used in authentication, and then presents it to the server. The server is the only element here serving the authentication process. 6 - Conceptual flaw - Binary outcome - There is either a pass or fail. There should be circumstances where the user would be either authenticated with restrictions or authenticated with trust warnings. Covering several trustable usages and / or coaction usage. SCOPE ePINSafe - EnhancedPINSafe This patent aims to solve flaws number 1, 2, 3, 4, 5 and 6 from above ABSTRACT enumeration. Assumption is that HTTPS has been compromised at all times and that further encryption must be supported. Encryption to be used is off standards and not discussed in this paper, as it's an implementation of 3rd party standards choice. The entire PINSafe mechanism is transited from the original patent, as the user receives a string of generated characters that he then uses the PIN in his possession, as a locator algorithm, for the extraction of an OTC, by using the numbers on the PIN as a positioner on the string, copying the character that the string has at that position, one by one, to generate an OneTimeCode. Offline generation of PINSafe securityStrings has always been done via a cache, maintained by and when a server connection was made available. An extended offline method was implemented for the Windows client that, though obfuscated, still leaves open the possibility for a decompilation and reverse engineering of the offline PINSafe generation routine, plus the storage and decryption of the PIN.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present application is a continuation-in-part of U.S. patent application Ser.

[0003] No.09 / 663, 281, filed Sep. 15, 2000, which claims priority from the U.K. Patent Application Number GB 0021964.2, filed Sep. 7, 2000, both of which are incorporated herein by reference in their entirety.

[0004] The present application refers to standards such as:

[0005] [OCRA] OCRA: OATH Challenge-Response Algorithms

[0006] [RFC 6030] Portable Symmetric Key Container

[0007] [OTIS] OATH Token Identifier specification

[0008] [ALG] Additional PSKC Algorithm Profiles

[0009] [NIST-800-63-1] NIST Special Publication 800-63-1, csrc.nist.gov / publications / nistpubs / 800-63-1 / SP-800-63-1.pdf, Dec.

[0010] 2011

[0011] FIELD OF THE INVENTION

[0012] The present invention relates to the field of secure transactions and more specifically to the verification of a user's identity for conducting transactions or digital / physical access authentication.

[0013] BACKGROUND OF THE INVENTION

[0014] The present invention relates to a needed upgrade / improvement over the original PINSafe patents already referenced in the CROSS-REFERENCE seccion.

[0015] At the time PINSafe was created, it was commonly and naively accepted in the industry that a website using HTTPS encryption on its’ pages, would be secure.

[0016] The entire purpose of PINSafe technology was to show that the transport layer was not to be trusted and as such no token should be sent in the clear to its destination and then interpreted and sent back in the exact same for os delivery, due to SMS interception, Email interception or possibility of physical token being stolen.

[0017] The logic implicit in PINSafe technology was correct but its implementation was fundamentally flawed as it only considered the problem at the delivery of a token and ignored the response problem, inherent to any authentication communication flow.

[0018] This issue was later made clear by an imperfect change of an imperfect design of the SwivelSecure mobile app (until version 4), that used a framework to build the code and that did not guarantee security against local attacks to the mobile app.

[0019] The same principles were then PoC’s by the team at SwivelSecure, charged with maintaining the technology, where a MiTM attack over HTTPS could be performed and the PIN compromised in a matter of seconds.

[0020] Because of those conclusions, a further critical look, from the hacker’s perspective was put in place by the same team, and several flaws were encountered and are now being fixed over the registration of new patents such as this. The purpose of the current patent filing (together with others associated with it), is to bring PINSafe edge back to its initial purpose, by correcting design and algorithm.

[0021] BRIEF SUMMARY OF THE INVENTION

[0022] According to the first aspect of the present invention, It is expected that the user has been given / has chosen a PIN (chosen as numbers and with a maximum size of 10 digits).

[0023] The server computer running the solution knows the user and the PIN.

[0024] Everytime an authentication is triggered, by means of user interaction or system automation, the user gets handed a security string (composed of a random string of 10 characters, that can range from numbers, to letters, to a mix of numbers and letters, small and capital, in form). The random string is based out of strong randomization seeding, independently of the used technology.

[0025] The user then creates a mental process or uses an application to perform the task for him, where the PIN gets converted into a positioning key to use against the string delivered. Each pin number would then be a positioning instruction, to fetch the corresponding order character on the existing string and the code needed to reply back to the server, extracted by iterating the digits on the pin and corresponding extraction from the security-string.

[0026] As an example:

[0027] Securitystring - ABCDEFGHIJ

[0028] PIN - 3512

[0029] Resulting OneTimeCode - CEAB

[0030] Per design the Security-string is generated per authentication request suffering randomization process each and everytime it’s requested.

[0031] This Algorithm is not changed at this improvement proposal. Changes focus from this point onwards.

[0032] The storing of the user PIN is also with a reversible encryption due to the fact that some older (legacy) integrations may force the OTC to be concatenated with the password field. This means the server needs to know the PIN size to then parse the password and the OTC out of the received password field. This means that the reversibility of the PINs can represent a liability in case of server database or backup compromise.

[0033] The fact that the PIN can be shared by unconscious users, brings a reactive nature to the solution. In the case of someone giving the PIN away, and allowing others to act on his behalf, can be sanctioned after a violation occurs. Admitting there is a way to prove.

[0034] Being a security solution, efforts must be made to allow the customer to enforce the PIN by other means that just trust. As such this patent adds the Biometric hash to the equation, allowing it to replace the seeding function for the OATH with a Biometric hash. ePINSafe Image Authentication - TURing image - Adding to the existing TURING image generation routine, the server randomises a key to support response encryption. This key is then embedded into the image data over steganography methodology.

[0035] Upon reception of Username, Password and OTC on the client side, the extraction of that key via steganography is fed to the encryption routine to protect the sensitive data (password + OTC) to be sent on the form Payload.

[0036] The server receives the reply to the already initialised authentication process and uses the known key to decipher the data. ePINSafe DualChannel Authentication - String over email / sms - Because there is no delivery endpoint control in this method, and because the endpoint to be used for the reply is also unknown, a pre-agreed method must be used.

[0037] In case of pre-provisioned entry points (PC client, PC VPN client or Mobile app) - The machine fingerprint is to be used as a seeding for an OATH HOTP engine that will continue to hoop the generated password per usage and auto-sync the server on successful authentication.

[0038] In case of loose entry points (VPN and for instance string over email) - The integration fingerprint (RADIUS secret for instance) is used as seed for a TOPT OATH implementation, being the time window part of the integration specification.

[0039] The generated OTP from the OATH function is used as password for the ciphering function, like previously described.

[0040] Extended implementation - Seamless trust - The secret sent from the server to the client, can be fed into an OATH TOTP implementation routine as seed and EPOCH Timestamp, and the key extracted, and used to cypher the data.

[0041] As data reaches the server, a multiple time-window is calculated, allowing for the authentication to gain trust levels, to feed a trust weight system.

[0042] Assuming the following setup:

[0043] Time Window for TOPT = 10 seconds

[0044] Standard Human interaction between receiving the image and entering the form data - 35 seconds.

[0045] Server gets a reply that matches the 4th authentication window - Trust level maximum

[0046] Server gets a reply that matches the 1st authentication window - Trust level Low

[0047] Server gets a reply that matches the 6th authentication window - Trust level Low

[0048] These examples can be extended or redefined for granularity, as per configurable options towards end customer use-case need.

[0049] Extended implementation - direct trust - The user may have registered more than one PIN. The usage of the PIN can then be attributed to trust sources. Example

[0050] PIN1 - full trust

[0051] PIN2 - wifi and low impact access points only

[0052] PIN3 - On behalf of (time bomb or single action bound for instance)

[0053] PIN4 - EMERGENCY - cohesion circumstance. Allow access but no action and alert immediately.

[0054] PINx - other function that may be use-case bound to the customer's needs.

[0055] PIN storage - The server stores not only the PIN or PINS due to direct trust enhancement, within a separate table (unlike previous PINSafe implementation).

[0056] That table includes not only the PIN information, but crucially the size of the PIN. Further data include the trust factor, human description of the PIN and eventual weighting system influence (+- points for instance).

[0057] The PIN size allows for the PIN to be stored HASHED. Since the PIN is numerical and so easily to reverse even hashed, the pin includes the server site's unique number, provided with licensing adding entropy and size to the hashing. BioLock - BioLock uses the biometric hashing (called pattern in the industry) to replace the seed on the ePINSafe protection mechanism.

[0058] Under this method, the user would use his biometric information on the terminal as a seed for the OAUTH function that generates the password to encrypt the form data.

[0059] This is being developed with our partner IB-Integrated biometrics solution in mind, so in that specific case, there are extra fields to be sent back to the server with trust settings. However, for other technologies that do not include trust settings, the time window can still be used as a trust setting.

[0060] Offline PINsafe - Offline pinsafe uses an extension to the OATH protocol that we are patenting alongside this patent.

[0061] Instead of a normal Securitystring generation, each endpoint and server get provisioned by a standard OAUTH seed and EPOCH time window.

[0062] When authentication OR verification is needed, the OAUTH protocol is then implemented to generate a 10-digit token.

[0063] Since the OATH token repeats digits, it would be impossible to be used as a seeding function for a Security String, because it wouldn’t be possible to reverse the PIN.

[0064] A simple mathematical transformation is then applied by adding the previous number on the token to the one being processed, so 1st nr, then 2nd+1st, then 3rd+2nd+1st, and so on.

[0065] Example.

[0066] Token generated from OATH - 6935624326

[0067] Transformed token - 6, 6+9, 6+9+3, 6+9+3+5, 6+9+3+5+6,

[0068] 6+9+3+5+6+2, 6+9+3+5+6+2+4, 6+9+3+5+6+2+4+3, 6+9+3+5+6+2+4+3+2, 6+9+3+5+6+2+4+3+2+6 = 6151823293135384046

[0069] A memory table containing a list of possible letters, numbers and special characters is default provided.

[0070] Example:

[0071] Table -

[0072] 1qaz!QAZ2wsx@WSX3edc#EDC4rfv$RFV5tgb%TGB6yhnAYHN7ujm&UJM8i k<*IK9OLol>0p?\|[}]{-_=+”. -,.... And so on.

[0073] A successful authentications counter on both server and client machine maintains the rotation hash on the table. The table then suffers a rotation around the index 0 so that it considers the number of hashes previous to it.

[0074] Example’.

[0075] Previous authentications - 11

[0076] Table -

[0077] The system will then display characters according to the transformed token. Example’.

[0078] Transformed token - 6,15,18,23,29,31 ,35,38,40,46

[0079] Previous authentications - 11

[0080] Table - Presented Securitystring - 3r$tByY7j8

[0081] User PIN - 3412

[0082] OTC - $t3r

[0083] Because the server knows the same data to seed, and EPOCH time and windows or temporal aperture, it can generate the same numbers exactly.

[0084] Because the successful login is acknowledged on both parts and incremented further, the rotation is known also, but a mechanism may be put in place to advance or retract x calculations to allow some slack on the table rotation login, much like the HOTP implementations used to.

[0085] The result is a string that can be generated offline and requires no constant access to the server, nor cache from the server.

[0086] Further, already described, methods for ciphering the content can be applied further during communication with the server. Since this is not communicated from server to client it is less prone to MiTM attack, but that theory drops on a secondary attack where the hacker has control over the victim screen, as such encryption is highly recommended in all scenarios.

[0087] Extended implementation - all above methods - It’s an offset implementation of the already described methods but takes into consideration the machine fingerprint.

[0088] Instead of the methods, using simple OATH calculation to generate seed for the Securitystring (Offline PINSafe) or the seed for the ciphering password (all other methods), the OATH OCRA extension is used, where the seed gets added 2 parameters more. One is the Machine fingerprint hash, the other is the network fingerprint hash.

[0089] The server has previous knowledge of the environments that the customer has provisioned from and normally users (by parameterization of security rules).

[0090] Instead of validating solely the authentication scenario, the server also calculates all possible authentication scenarios that the user can connect from and are authorised to do.

[0091] The result is that the authentication is not only for the user, but also, authorised machine and origin.

[0092] Example:

[0093] Seed for ciphering authentication - JBSWY3DPEHPK3PXP

[0094] Machine fingerprint hash - 4VM1 N12

[0095] Network fingerprint hash - myhomewifi

[0096] Concateration - JBSWY3DPEHPK3PXP~4VM1 N12~myhomewifi SHA256 - f 1338f96928caed7b219280abab9e7778ee479b0cdb738e6a3a 1 f27c8f67bea4 This becomes the seed for the TOTP

[0097] The server, assuming the user has enabled location for Computer + Home wifi and Computer + VPN, will have to match 2 different calculations, but in doing so can clearly point the user is who he claims to be, from a known and expected location, and do this seamlessly.

Claims

AMENDED CLAIMS received by the International Bureau on 25 February 2025CLAIMS1 . A method for multifactor / 2 factor / single factor authentication of users and machines, comprising: a. An extension of patent GB 2 502 773 A (SWIVEL SECURE LTD [GB]) 11 December 2013 - PINSAFE, by fixing the unprotected and unencrypted payload and consequent MiTM vulnerabilities, Offline generation issues and machine to machine incapabilities (PINSafe is user to machine authentication only). As per PINSafe patent description,” A secure method to recognize a person, system or machine, by assigning a PIN and using it to digest a randomised string into an OTC (One Time Code), independently of the existence or not of direct communication between the authenticator machine and authenticated part” b. An embedded method to encrypt the payload of the information that supports authentication, using: i. User to system - when a user logs into a system than delegates the authentication part on the authentication server, but further interaction between the user and the server happen to prove authentication claim:

1. With PKI certificate : The Authentication server uses PKI implementation to cypher the encryption passwords as it passed on to the client authenticating machine .The standard PublicKeylnterface will be used to encrypt the password, embed it into the image via steganography and decrypt once reached the authenticating client machine. The authentication payload will be encrypted with the password passed with this secure way.

2. With Biometrics : The Authentication server uses Biometrics to support the encryption of the authentication payload.In essence, the PKI is replaced by the username hash and the user biometric patent hash.

3. With OATH : the Encryption of the Payload encryption password while in transport to the user computer is guaranteed by using OATH TOTP functions. Due to the timebox nature, and to guarantee that the system works, the payload has 3 copies of the string with the current timebox, +- 1 timebox. To guarantee correct deciphering, a checksum string is added to the password and checked on the receiving computer. The rest is equal by using the password to encrypt the authentication payload.

4. With Machine Fingerprint : Same principle as before, however in this example the password for authentication payload encryption is sent with using the machine fingerprint to support the encryption and safeguard the transference of the authentication payload password from server to client machine.ii. System to system - when a computer needs to automatically be authenticated to another computer without human interaction or interference. c. An offline method to generate the randomization string out of OATH protocol transformation. This leverages the OAth standard to be used as a base seed on the generation of Security Strings, to be used offline, as described in patent GB 2 502 773 A (SWIVEL SECURE LTD [GB]) 11 December 2013. This patent does not cover offline generation of Securitystrings to support PINSafe extraction of OTC.We propose to use the same seeding methods that support OATH TOTP / HOTP OTC generation, but then extends this OTC into 10 Digits and further fixes character reusability often seen in OATH OTC tokens.To fix this limitation, we propose an extension to OATH protocol to support further security and machine to machine encryption seeding and authentication seeding, assuming OATH seed compromise.With OATH the entire security lies in the SEED and token Serial. This patent tries to include a unique randomization number to extend the OATH 6 digital to a 10 digit with unique digits (for security string generation) together with a salting algorithm to generate a cypher table that rotates per install in a manner that only the machines in communication with each other can understand. d. A secure method to enhance two factor, over SMS or email, assuming transport media compromise and payload compromised2. A method for multifactor / 2 factor / single factor seamless authentication of users and machines, comprising: a. Ecosystem trust values (authentication object historic data, location data and devices around him / it) b. Interaction time trust values (system definable expected authentication challenge reply time for human or machine) c. An extension of claim nr 1 (PIN usage to digest an OTC), to support several PINS, allowing the system configuration to decide security trust levels, pending on the PIN that is used at authentication.

3. A method for augmenting Biometrics (identification) into full authentication of users and machines (machine ID as biometric hash), comprising: a. Using Claim nr 1 (PIN usage to digest an OTC) as a secondary method of biometric identification, to provide authentication, whenever needed, either by system policy or biometric reading out-of-threshold (dead tissue, gel copy of tissue, abnormal temperature, etc).Most biometric readers in business try to gather not only the biometric information but also environmental values from that data, for instance, a finger that is too cold, a finger with no moisture, a static image, etc.Most drivers then add the reading and recognizing of the biometric patent as main output and eventually the threshold of the reading.By implementing ePINsafe, we can add validation of the biometric reading instead of just the threshold. b. Using biometric or machine ID to support the encryption of payload of authentication, supporting both identification and also cyphering security against payload compromise attacks.

Images