EP4372585A1 - Systèmes et procédés sécurisés pour jetons numériques - Google Patents

Systèmes et procédés sécurisés pour jetons numériques Download PDF

Info

Publication number
EP4372585A1
EP4372585A1 EP23199668.7A EP23199668A EP4372585A1 EP 4372585 A1 EP4372585 A1 EP 4372585A1 EP 23199668 A EP23199668 A EP 23199668A EP 4372585 A1 EP4372585 A1 EP 4372585A1
Authority
EP
European Patent Office
Prior art keywords
computing device
token
certain embodiments
identification code
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23199668.7A
Other languages
German (de)
English (en)
Inventor
Lalith Chinta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Barclays Execution Services Ltd
Original Assignee
Barclays Execution Services Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Barclays Execution Services Ltd filed Critical Barclays Execution Services Ltd
Publication of EP4372585A1 publication Critical patent/EP4372585A1/fr
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos

Definitions

  • This disclosure relates to techniques for efficiently managing and storing digital tokens for accessing a protected resource at a client system on behalf of a user.
  • a digital token (for example, an access token or a refresh token) is an electronic credential used in a process of gaining access to digital information based on consent from an entity with a right to grant access to that digital information, such as the owner of the digital information.
  • Service providers such as credit reporting agencies and insurance companies may store previously-issued digital tokens for a large number of their customers in a digital token store and present those digital tokens (for example, to bank or hospital systems, respectively) to obtain sensitive information about their customers (such as financial and medical information, respectively).
  • a digital token store is an attractive target for a nefarious actor seeking to compromise the store in an effort to gain access to customers' sensitive information and/or perform actions with the permissions of customers' accounts.
  • Digital token encryption provides only a partial solution because, for example, a store of encryption keys maintained by the service provider may be equally vulnerable to being compromised.
  • malware can acquire data while it is in motion in a compromised system, for example, from the system's memory components such as registers, caches, and RAM.
  • Certain embodiments may provide, for example, a computer-implemented method for securing the use of digital tokens (for example, access tokens or refresh tokens) in network environments (for example, in networks that include servers of a branded entity and a plurality of their customer's mobile devices).
  • digital tokens for example, access tokens or refresh tokens
  • network environments for example, in networks that include servers of a branded entity and a plurality of their customer's mobile devices.
  • the computer-implemented method may comprise: i) encrypting a digital token using an identification code for a computing device (for example, a symmetric encryption key that also serves to identify a designated mobile device) to form an encrypted digital token; assigning the encrypted digital token to the computing device; iii) transmitting the identification code to the computing device; and iv) expunging (for example, permanently deleting from volatile and/or non-volatile memory) the digital token and the identification code.
  • the computer-implemented method may further comprise generating the identification code using symmetric cryptography.
  • the identification code is transmitted to the computing device via a web browser of the computing device.
  • the identification code may be a private corresponding to a public key (for example, a public key-private key pair generated by asymmetric cryptography).
  • the computer-implemented method may further comprise storing the encrypted digital token in a database.
  • the computer-implemented method may further comprise storing the encrypted digital token remotely from the computing device.
  • the computing device may be a customer's computing device (for example, a customer's smartphone or personal computer).
  • the computing device may be an employee's computing device (for example, a company issued smartphone or personal computer such as a laptop).
  • the identification code may be stored in a secure enclave of the computing device.
  • Certain embodiments may provide, for example, a client system (for example, a branded entity's computing infrastructure or a financial institution's computing infrastructure that includes one or more servers and/or databases) for securing the use of digital tokens in network environments.
  • the client system may comprise: i) one or more servers programmed to: a) encrypt a digital token using a identification code for a computing device to form an encrypted digital token; b) assign the encrypted digital token to the computing device; c) transmit the identification code to the computing device; and d) expunge the digital token and the identification code; ii) a database, the database configured to store the encrypted digital token remotely from the computing device; and iii) one or more software components, the one or more software components configured to store the identification code on the computing device.
  • a mobile app may comprise the one or more software components.
  • the one or more software components may be configured to store the identification code in a secure enclave on the computing device.
  • the client system may be configured to obtain the digital token from a resource system based on an authorization grant received from the computing device.
  • Certain embodiments may provide, for example, a product for securing the use of digital tokens in network environments (for example, a product configured to be used in an entity's networked computing infrastructure), the product comprising a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform token management operations.
  • the token management operations may comprise: i) encrypting a digital token using an identification code for a computing device to form an encrypted digital token; ii) assigning the encrypted digital token to the computing device; iii) transmitting the identification code to the computing device; and iv) expunging the digital token and the identification code.
  • the token management operations may further comprise: communicating with a downloadable mobile app on the computing device (or, for example, via a web browser on the computing device) to transmit the identification code.
  • the token management operations may further comprise receiving the identification code from the computing device.
  • the token management operations may comprise decrypting the encrypted digital token using the identification code to recover the digital token.
  • the token management operations may comprise requesting one or more protected resources associated with the digital token.
  • the requesting may comprise transmitting the digital token to a resource system.
  • the token management operations may comprise processing a response to the requesting.
  • the response may comprise the one or more protected resources.
  • the present disclosure is based, generally, on the discovery that each customer of a client entity can substantially mitigate the risk that the client entity's digital token store will be compromised by storing a token encryption key (for decrypting an encrypted digital token) as a non-public device identification code in secured memory of the customer's computing device.
  • Token management operations based on this discovery allow the client entity expunge the token encryption key and an unencrypted digital token from its volatile and non-volatile memory, retaining only the customers' encrypted digital tokens (for example, in a database).
  • the present disclosure is further specifically based, in part, on the discovery that, even if a nefarious actor is aware that the technique is being employed, such knowledge does not short circuit the security provided by the technique.
  • FIG. 1 shows a use case (100) in which a customer (102) purchases (114) an item from a merchant (106) (i.e., the "client entity” in this use case) using a credit card (104). The customer then reviews financial details of the transaction (and optionally other transactions) via an app on the customer's handheld mobile device (112) such as a smartphone.
  • the credit card (104) is co-branded by a financial services company (108) that finances credit card transactions and a branded entity (110) such as a branded company.
  • Transaction information (116) is supplied to the financial services company (108).
  • the app on the customer's handheld mobile device (112) requests (118) the information by submitting a message to the branded entity (110) that includes a request for transaction information and a non-public identification code for the customer's handheld mobile device (112) to the branded entity (110).
  • the branded entity (110) uses the non-public identification code to decrypt an access token to obtain an unencrypted access token and then submits a request (120) to the financial services company (108) by submitting a message to the financial services company (108) that includes the unencrypted access token and the request for transaction information. Concomitant with the request (120), the branded entity (110) expunges the non-public identification code and the unencrypted access token from its system.
  • the financial services company (108) verifies the right of the branded entity (110) to receive the transaction information and then sends (122) the transaction information to the branded entity (110). Finally, the branded entity (110) responds (124) to the request (118) with the transaction information, which is displayed for the customer (102) to view using an interface (126) associated with the app on the customer's handheld mobile device (112).
  • certain embodiments may provide, for example, methods, systems, products, software (for example, one or more software components such as one or more software modules), computing infrastructure and/or apparatus for securing any kind of digital token in relation to a resource owner where the resource owner controls their own computing device.
  • software for example, one or more software components such as one or more software modules
  • computing infrastructure and/or apparatus for securing any kind of digital token in relation to a resource owner where the resource owner controls their own computing device.
  • the protocol (200) involves four entities: a resource owner (202), a client entity (204), an authorization entity (206), and a resource entity (208).
  • the protocol (200) can be a protocol for the Open Authorization 2.0 framework ("OAuth"), the SAML framework, or the OpenID framework, or another framework providing a protocol.
  • OAuth Open Authorization 2.0 framework
  • SAML framework the SAML framework
  • OpenID framework the OpenID framework
  • the resource owner (202) is capable of granting access to a protected resource.
  • the resource owner (202) can be the customer (102) discussed with respect to FIG. 1 who may wish to grant the branded entity (110) access to a protected resource so that the protect resource can be displayed to the customer (102) using the interface (126) associated with the app on the customer's handheld mobile device (112).
  • the resource owner (202) can be one or more of a consumer, borrower, potential tenant, and the like who wishes to grant a third party request from a financial institution, mortgage lender, landlord, and the like to access the resource owner's financial information held by a third-party source such as a bank.
  • the resource owner (202) can be a patient who wishes to allow a third party such as a medical provider, insurance company, pharmacy, and the like to access the patient's medical record information.
  • the client entity (204) is an entity, or an application, that, when authorized by the resource owner (202), can request access to the protected resource on behalf of the resource owner (202),.
  • client entities include entities that aggregate information for customers, entities that sponsor financial products, other financial intermediaries such has credit card companies and consumer reporting agencies.
  • Examples of credit card companies within in the scope of the disclosure include, but are not limited to, credit cards issued by American Express, Bank of America, Barclays, Capital One, Chase Bank, Citibank, Discover, Mastercard, Navy Federal Credit Union, Pentagon Federal Credit Union, PNC, United Services Automobile Association, U.S. Bank, Visa, and Wells Fargo.
  • consumer reporting agencies within the scope of the disclosure include but are not limited to consumer credit reporting agencies, employment screening agencies, tenant screening agencies, check and bank screening agencies, auto and property insurance reporting agencies, medical information agencies, low-income and subprime reporting agencies, supplementary report agencies, and consumer utility reporting agencies.
  • Examples of consumer reporting agencies falling in the scope of the disclosure include but are not limited to Equifax, TransUnion, Experian, DISA Global Solutions, Inc., Asurint, CCC Verify, Cisive, Social Intelligence, uConfirm, AmRent, Universal Background Screening, National Cred-A-Check, Inc., Accurate Background, backgroundchecks.com, Certegy Payment Solutions, LLC, National Consumer Telecom & Utilities Exchange (NCTUE), Info Cubic, LLC, Pre-employ.com, LexisNexis C.L.U.E. (Auto & Property Reports), Insurance Information Exchange (iiX), DataX, ADP Screening & Selection Services, Inc., Innovis, The Work Number, CoreLogic Credco, EmpInfo, and HireRight.
  • the authorization entity (206) is an entity that grants and issues access tokens to the client entity (204) after authenticating the resource owner and obtaining authorization.
  • the authorization entity (206) can also issue refresh tokens. If the authorization entity (206) issues a refresh token, can be included when issuing an access token.
  • the resource entity (208) is an entity that hosts the protected resource and is capable of accepting and responding to requests for the protected resource using access tokens.
  • the client entity (204) requests authorization from the resource owner (202) for access to the protected resource.
  • the authorization request can be made directly to the resource owner (202), or indirectly via the authorization entity (206) as an intermediary.
  • the client entity (204) receives an authorization grant, which is a credential representing the authorization provided by the resource owner (202).
  • the authorization can be expressed using one of a plurality of "grant types" that depends on the method(s) used by the client entity (204) to request authorization and the type(s) supported by the authorization entity (206).
  • the client entity (204) requests an access token by authenticating with the authorization entity (206) and presenting the authorization grant.
  • the authentication can be expressed using one of a plurality of "authentication types" for authenticating the client entity (204) at the authorization entity (206).
  • the authentication type depends on the method(s) used by the client entity (204) to authenticate itself and the type(s) supported by the authorization entity (206).
  • step (216) the authorization entity (206) authenticates the client entity (204) and validates the authorization grant, and if valid, issues an access token.
  • step (218) the client entity (204) requests the protected resource from the resource entity (208) and authenticates itself at the resource entity (208) by presenting the access token to the resource entity (208).
  • step (220) the resource entity (208) validates the access token. If the access token is valid, the resource entity (208) serves the request by transmitting the protected resource to the client entity (204).
  • Certain embodiments may provide, for example, methods, systems, products, computer executable instructions, software, computing infrastructure and/or apparatus for a client system of the client entity to secure any kind of digital token.
  • the computer-executable instructions may comprise instructions to generate a code.
  • the code may be cyphertext.
  • the code may be generated by a quantum random number generator.
  • the code may be an identification code.
  • the code may be a code to identify a computing device.
  • the code may be a dual-purpose code.
  • a first purpose of the dual-purpose code may be to serve as a non-public device identification code for the computing device.
  • a client system that creates the dual-purpose code may credit receipt of the dual-purpose code from the computing device as a form of authentication of the computing device (for example, to guard against a "man-in-the-middle" attack).
  • a second purpose of the dual-purpose code may be to serve as a decryption key for information (for example, an encrypted digital token such as an access token or a refresh token stored on the client system).
  • the computer-executable instructions may use the non-public identification code as an encryption key to encrypt and/or decrypt a digital token with a symmetric encryption algorithm.
  • the symmetric encryption algorithm may be selected from the group consisting of Triple Data Encryption Algorithm (3DES), Advanced Encryption Standard (AES), Camelia (Block cipher developed by Mitsubishi and NTT), Data Encryption Standard (DES), Fortezza (Security token based cipher), GOST (Block cipher developed in USSR), International Data Encryption Algorithm (IDEA), Rivest Cipher 2 (RC2), Rivest Cipher 4 (RC4), and SEED (Block cipher developed by Korean Information Security Agency).
  • 3DES Triple Data Encryption Algorithm
  • AES Advanced Encryption Standard
  • Camelia Block cipher developed by Mitsubishi and NTT
  • Data Encryption Standard DES
  • Fortezza Security token based cipher
  • GOST Block cipher developed in US
  • the computer-executable instructions may generate a plurality of such non-public identification codes corresponding to a plurality of computing devices (for example, the computing devices of resource owners).
  • the correspondence may be a 1-to-1 correspondence between the non-public identification codes and the computing devices such that each computing device corresponds to a distinct non-public identification code.
  • the correspondence may be an N-to-M correspondence between the non-public identification codes and the computing devices where N and M are integers, such that N non-public identification codes corresponds to M computing devices (for example, a single non-public identification code could correspond to each computing device identified and associated with the resource owner).
  • the computer-executable instructions may generate a non-public identification code (or plural non-public identification codes) using key generation in accordance with a symmetric encryption algorithm.
  • the computer-executable instructions may use the non-public identification code as an encryption key (for example, a private key) to encrypt and/or decrypt a digital token with an asymmetric (or public key) encryption algorithm.
  • the asymmetric encryption algorithm may be selected from the group consisting of Rivest-Shamir-Adleman (RSA), Elliptic Curve Digital Signature Algorithm (ECDSA), Digital Signature Algorithm (DSA), or Diffie-Hellman key agreement protocol.
  • the non-public identification code may be random cyphertext generated by quantum random number generator.
  • the computer-executable instructions may generate a plurality of such non-public identification codes corresponding to a plurality of computing devices (for example, the computing devices of resource owners).
  • the correspondence may be a 1-to-1 correspondence between the non-public identification codes and the computing devices such that each computing device corresponds to a distinct non-public identification code.
  • the correspondence may be an N-to-M correspondence between the non-public identification codes and the computing devices where N and M are integers, such that N non-public identification codes corresponds to M computing devices (for example, a single non-public identification code could correspond to each computing device identified and associated with the resource owner).
  • the computer-executable instructions may generate an non-public identification code (or plural non-public identification codes) using key generation in accordance with an asymmetric encryption algorithm.
  • the non-public identification code may the product of a hashing algorithm.
  • the hashing algorithm may be selected from the group consisting of BLAKE-256, BLAKE-512, BLAKE2s, BLAKE2b, Elliptic Curve Only Hash (ECOH), the Fast Syndrome-based (FSB) hash, GOST, Grostl, HAS-160, HAVAL, JH, the Message Digent-2 (MD2) algorithm, MD4, MD5, MD6, RadioGat ⁇ m, the RACE Integrity Primitives Evaluation Message Digest (RIPEMD), RIPEMD-128, RIPEMD-160, RIPEMD-320, the Secure Hash Algorithm-1 (SHA-1), SHA-2, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, Skein, Snefru, Spectral Hash, Streebog, SWIFFT, Tiger, Whirlpool-0, Whirlpool
  • ECOH Elliptic Curve Only Hash
  • the computer-executable instructions may comprise instructions to manage information in the volatile memory.
  • the computer-executable instructions may comprise computer-executable instructions to expunge information from the volatile memory.
  • the computer-executable instructions to expunge information may comprise de-allocating and/or overwriting specified memory addresses in the volatile memory.
  • the specified memory addresses may comprise those storing the code (for example, the non-public identification code).
  • the overwriting of specified memory addresses may comprise overwriting the specified memory addresses with one or more predetermined values.
  • Certain embodiments may provide, for example, methods, systems, products, computer executable instructions, software, computing infrastructure and/or apparatus for a computing device (for example, a computing device of the resource owner such as a customer's mobile computing device) to secure a code (for example, a dual-purpose code as described above).
  • a computing device for example, a computing device of the resource owner such as a customer's mobile computing device
  • a code for example, a dual-purpose code as described above.
  • the computer executable instructions may be invoked using one or more web browsers.
  • the one or more web browsers may be selected form the group consisting of the Microsoft Edge web browser, the Google Chrome web browser, the Apple Safari web browser, the Brave web browser, the Cake web browser, the Firefox web browser, or a combination of two or more of the foregoing web browsers.
  • the one or more web browsers may comprise a mobile browser.
  • the one or more web browsers may comprise a web browser with strong authentication support (for example, FIDO2 Strong Authentication Support).
  • the web browser with strong authentication support may be selected from a group consisting of the Microsoft Edge web browser, the Google Chrome web browser, the Apple Safari web browser, or the Firefox web browser.
  • the one or more web browsers may comprise a web browser with HTTP Cookie storage support.
  • the computer executable instructions may be software in the form of a browser extension. In certain embodiments, for example, the computer executable instructions may be in the form of a plug-in. In certain embodiments, for example, the computer executable instructions may be in the form of an add on.
  • the computing device may comprise one or more storage media for electronic information.
  • the one or more storage media may comprise one or more transitory or non-transitory machine-readable (for example, computer-readable) storage media (for example, memory, data storage, etc.), which may be read and executed by one or more processors.
  • machine-readable storage media may be one or more storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (for example, a volatile or non-volatile memory, a media disc, or other media device).
  • the storage media may comprise one or more regions of memory including software that are isolated from other software executed by the processor.
  • the storage media may provide a trusted execution environment.
  • the trusted execution environment may comprise one or more secure enclaves.
  • the one or more secure enclaves may be embodied as a protected region of storage media.
  • the one or more secure enclaves may include software and/or data (for example, a non-public identification code for the computing device).
  • the software and/or data may be measured, validated, or otherwise authenticated.
  • the secure enclave may protect such software and/or data from access by software executing outside of the same secure enclave.
  • the software and/or data in the secure enclave may be protected from access and/or tampering using any combination of hardware protection and/or cryptographic protection.
  • Certain embodiments may provide, for example, methods, systems, products, computer executable instructions, software, computing infrastructure and/or apparatus for networked communications between computing resources of a resource owner, a client entity, an authorization entity, and a resource entity.
  • part or all of the networked communications may proceed through one or more network tunnels (for example, part or all of the communications between the resource owner's computing resources and the client entity's computing resources may proceed through one or more network tunnels, part or all of the communications between the client entity's computing resources and the authorization entity may proceed through one or more network tunnels, and/or part or all of the communications between the client entity's computing resources and the resource entity may proceed through one or more network tunnels).
  • one or more network tunnels may be negotiated wherein one or more encryption keys is established by executing a key exchange algorithm between communication endpoints.
  • the key exchange algorithm may be selected from the group consisting of Rivest, Shamir, Adleman (RSA), Diffie-Hellman (DH), Diffie-Hellman Ephemeral (DHE), Elliptic-Curve Diffie-Hellman (ECDH), Kerberos (KRB5), Secure Remote Password Protocol (SRP), Pre-shared key (PSK), Digital Signature Algorithm (DSA), Elliptic Curve Digital Signature Algorithm (ECDSA), and Digital Signature Standard (DSS).
  • Rivest Rivest
  • Shamir Adleman
  • Diffie-Hellman Diffie-Hellman Ephemeral
  • ECDH Elliptic-Curve Diffie-Hellman
  • KRB5 Kerberos
  • SRP Secure Remote Password Protocol
  • PSK Pre-shared key
  • DSA Digital Signature Algorithm
  • EDSA Elliptic Curve Digital Signature Algorithm
  • DSS Digital Signature Standard
  • information communicated via the one or more network tunnels may be encrypted using a symmetric encryption algorithm prior to transmitting the information via the network tunnel.
  • the symmetric encryption algorithm may be selected from the group consisting of Triple Data Encryption Algorithm (3DES), Advanced Encryption Standard (AES), Camelia (Block cipher developed by Mitsubishi and NTT), Data Encryption Standard (DES), Fortezza (Security token based cipher), GOST (Block cipher developed in USSR), International Data Encryption Algorithm (IDEA), Rivest Cipher 2 (RC2), Rivest Cipher 4 (RC4), and SEED (Block cipher developed by Korean Information Security Agency).
  • 3DES Triple Data Encryption Algorithm
  • AES Advanced Encryption Standard
  • Camelia Block cipher developed by Mitsubishi and NTT
  • Data Encryption Standard DES
  • Fortezza Security token based cipher
  • GOST Block cipher developed in USSR
  • information communicated between endpoints may be encrypted using quantum cryptography, for example, via quantum key distribution, a mistrustful quantum cryptography technique, a bounded or noisy quantum storage technique, or a position-based quantum cryptography technique.
  • information communicated via the one or more network tunnels may be hashed (for example, salted and hashed) prior to transmitting the information via the network tunnel.
  • the hashed value may be obtained by passing the portion of the data packet through a hashing algorithm.
  • the hashing algorithm may be selected from the group consisting of BLAKE-256, BLAKE-512, BLAKE2s, BLAKE2b, Elliptic Curve Only Hash (ECOH), the Fast Syndrome-based (FSB) hash, GOST, Grostl, HAS-160, HAVAL, JH, the Message Digent-2 (MD2) algorithm, MD4, MD5, MD6, RadioGat ⁇ m, the RACE Integrity Primitives Evaluation Message Digest (RIPEMD), RIPEMD-128, RIPEMD-160, RIPEMD-320, the Secure Hash Algorithm-1 (SHA-1), SHA-2, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, Skein, Snefru, Spectral Hash, Streebog, SWIFFT, Tiger, Whirlpool-0, Whirlpool-T, and Whirlpool.
  • ECOH Elliptic Curve Only Hash
  • FSB Fast Syndrome-based
  • a system (300) in accordance with an embodiment of the present disclosure comprising a computing device (302), a client system (304), an authorization system (312), and a resource system (314).
  • the authorization system (312) and the resource system (314) can be part of an optional combined external system (310).
  • the computing device (302) is configured for communication (322) with the client system (304).
  • the client system (304) is configured for communication (324) with the authorization system (312), directly or optionally via the optional combined external system (310).
  • the client system (304) is also configured for communication (326) with the resource system (314), directly or optionally via the optional combined external system (310).
  • the computing device (302) can be a computing device of the resource owner (202) in communication with the client system (304) of the client entity (204).
  • the computing device (302) comprises an customer engine (318) having instructions executable by the computing device (for example, a downloaded app) for performing computing operations.
  • the customer engine (318) can comprise one or more modules (for example, one or more software modules) that, when executed, provides a user-interface, controls a camera, process information received via communication (322), cause information to be communicated via communication (322), and/or access information present in a storage media (320) for electronic information.
  • the computing device (302) comprises the storage media (320) for electronic information.
  • the storage media (320) can include one or more regions of memory including software that are isolated from other software executed by the processor (for example, a secure enclave).
  • the client system (304) is configured to access data stored at the resource system (314), subject to permission from a resource owner (202).
  • the client system (304) can be a system controlled by a client entity (204).
  • the client system (304) comprises a client engine (306), a volatile memory (308), and a nonvolatile memory (316).
  • the client system (304) is configured for communication (322) with the computing device (302), communication (324) with the authorization system (312), and communication (326) with the resource system (314).
  • the client system (304) can comprise one server, one or more servers, or a plurality of servers.
  • the client engine (306) comprises first instructions for communication (324) with the authorization system (312) to retrieve an access token (or a refresh token).
  • the client engine (306) comprises second instruction to store the retrieved access token in volatile memory of the client system (304).
  • the client engine (306) does not store the access token in nonvolatile memory (316) of the client system (304).
  • the client engine (306) comprises third instructions to generate an identification code for the computing device (302) solely in volatile memory (308) of the client system (304).
  • the identification code can be a private key generated with and a public key using asymmetric cryptography.
  • the client engine (306) does not store the identification code in nonvolatile memory (316) of the client system (304).
  • the client engine (306) comprises fourth instructions to encrypt the access token using the identification code.
  • the client engine (306) comprises fifth instructions to expunge the identification code and the access token from the volatile memory (308).
  • the fifth instructions to expunge can include de-allocation and overwriting of those memory addresses in the volatile memory (308) associated with the identification code and the access token.
  • the fifth instructions to expunge can be executed proximate completion fourth instructions to encrypt the access token.
  • the overwriting of memory addresses can comprise overwriting the memory addresses with a predetermined value.
  • the first through fifth instructions, the identification code, and the access token can be protected from access and/or tampering using any combination of hardware protection and/or cryptographic protection that are isolated from other software executed by the client system (304).
  • the first through fifth instructions, the identification code, and the access token can be secured in one or more protected regions of the volatile memory (308).
  • the authorization system (312) is configured to authorize requests for access to protected resources that are stored at the resource system (314).
  • the authorization system (312) can comprise the authorization entity (206).
  • the authorization system (312) can comprise a plural servers or a single server.
  • the resource system (314) is configured to store data associated with users of devices, such as the computing device (302).
  • the data stored at the resource system (314) can comprise protected resources, such as one or more secure data items.
  • the resource system (314) can be a system controlled by a resource entity (208).
  • Each of the one or more protected resources is prevented from being sent to a device or a system that is remote and distinct from the resource system (314), such as the client system (304), without the corresponding user providing authorization to the resource system (314) for the one or more protected resources to be sent to a remote device or system.
  • Each of the one or more protected resources can be indicative of private information relating to a user of the resource system (314).
  • each data item stored at the resource system (314) comprises financial data relating to the user, such as details that enable the user to make payments or the details of previous financial transactions made by the user.
  • the resource system (314) can comprise the resource entity (208).
  • the resource system (314) can comprise one server, one or more servers, or a plurality of servers.
  • One of the client system (304), authorization system (312), and resource system (314) can be separately controlled from the other two systems.
  • one or more of the client system (304), authorization system (312), and resource system (314) can be commonly controlled.
  • the client system (304) and authorization system (312) can be commonly controlled while the resource system (314) is separately controlled.
  • the client system (304) and resource system (314) can be commonly controlled while the authorization system (312) is separately controlled.
  • the authorization system (312) and resource system (314) can be commonly controlled while the client system (304) is separately controlled.
  • the client system (304), authorization system (312), and resource system (314) can be commonly controlled.
  • the optional combined external system (310) can comprise a plurality of sub-systems, for instance, a plurality of servers.
  • the optional combined external system (310) comprises the authorization system (312) and the resource system (314).
  • Each one of the computing device (302), client system (304), authorization system (312), and resource system (314) comprise a networked electronic device whereby communications (322), (324), and (326) can be implemented using any suitable communications protocol and connection, including a wired and/or a wireless connection.
  • Certain embodiments may provide, for example, a computer-implemented method for securing the use of one or more digital tokens.
  • Certain embodiments may comprise, for example, a product for securing the use of digital tokens (for example, access tokens).
  • the product may comprise a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform token management operations.
  • Certain embodiments may comprise, for example, a system for securing the use of digital tokens in network environments.
  • the system may comprise a networked system controlled by an entity (for example, a client entity) that interacts with other entities on the network (for example, interacts with a computing device and an authorization system via the public Internet).
  • FIG. 4 there is shown token management operations for securing an access token in a network environment (400).
  • a client engine (306) of a client system (304) requests authorization from a customer engine (318) of a computing device (302) for access to the protected resource.
  • the authorization request in step (410) can be made directly to the customer engine (318) of the computing device (302), or indirectly via the authorization system (312) as an intermediary.
  • the client engine (306) of the client system (304) receives a grant to access a protected resource from the customer engine (318) of the computing device (302).
  • the grant may be expressed using one of a plurality of "grant types" described in the Authorization Framework of OAuth, and the grant type depends on the method(s) used by the client engine (306) of the client system (304) to request authorization and the type(s) supported by the authorization system (312).
  • the client engine (306) of the client system (304) requests an access token by authenticating with the authorization system (312) and presenting the authorization grant.
  • the authentication may be expressed using one of a plurality of "authentication types" for authenticating the client system (304) at the authorization system (312), and the authentication type depends on the method(s) used by the client engine (306) of the client system (304) to authenticate itself and the type(s) supported by the authorization system (312).
  • step (414) the authorization system (312) authenticates the client engine (306) of the client system (304) and validates the authorization grant, and if valid, issues an access token to the client engine (306) of the client system (304). If the authorization grant is validated in step (414), the authorization system (312) may also optionally issue a refresh token for the access token to the client engine (306) of the client system (304).
  • step (416) the client engine (306) of the client system (304) encrypts the access token using an identification code for a computing device to form an encrypted access token. If the optional refresh token was received from the authorization system (312) in step (414), then the client engine (306) of the client system (304) encrypts the refresh token in step (416) using the identification code for the computing device to form an encrypted refresh token.
  • step (418) the client engine (306) of the client system (304) assigns the identification code to the computing device.
  • step (420) the client engine (306) of the client system (304) transmits the identification code to the computing device (302).
  • step (422) the client engine (306) of the client system (304) expunges the access token and the identification code from the client system (304).
  • the client engine (306) of the client system (304) may store the encrypted access token (or any other kind of digital token such as a refresh token) in a nonvolatile memory (316) of the client system (304).
  • the customer engine (318) of the computing device (302) may store the identification code in a storage media (320) of the computing device (302).
  • token management operations (500) for using a secured access token in a network environment there is shown.
  • step (502) the customer engine (318) of the computing device (302) retrieves the identification code (for example, a dual non-public identification code and private key for decrypting the encrypted access token) from the nonvolatile memory (316).
  • the identification code for example, a dual non-public identification code and private key for decrypting the encrypted access token
  • step (504) the customer engine (318) of the computing device (302) transmits the identification code to the client engine (306) of the client system (304).
  • step (506) the client engine (306) of the client system (304) retrieves the encrypted access token from the nonvolatile memory (316) of the client system (304).
  • step (508) the client engine (306) of the client system (304) decrypts the encrypted access token to obtain the access token.
  • step (510) the client engine (306) of the client system (304) transmits the access token obtained in step (508) with a request for a protected resource to the resource system (314).
  • step (512) the client engine (306) of the client system (304) expunges the access token and the identification code from the client system (304).
  • step (514) the resource system (314) determines whether the access token is valid. If the access token is valid, then the resource system (314) transmits the protected resource to the client engine (306) of the client system (304).
  • the client engine (306) of the client system (304) transmits the protected resource to the customer engine (318) of the computing device (302).
  • FIG. 6 there is shown a block diagram illustrating a mobile computing device (600) architecture in accordance with an exemplary embodiment.
  • a mobile computing device 600
  • a person of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device.
  • at least one processor device and a memory may be used to implement the above described embodiments.
  • the mobile computing device (600) can comprise a single hardware processor, a plurality of hardware processors, or combinations thereof. Each hardware processor can have one or more processor "cores.”
  • Hardware processor (606) can be a special purpose or a general purpose processor device.
  • the hardware processor (606) can be connected to a communication infrastructure (608), such as a bus, message queue, network, multi-core message-passing scheme, etc.
  • the network can be any network suitable for performing the functions as disclosed herein and can include a local area network (LAN), a wide area network (WAN), a wireless network (for example, Wi-Fi) such as Bluetooth, a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), networks using the global positioning system (GPS) platform, networks using ultra-wideband or pulse radio, any other suitable communication network, or any combination thereof.
  • LAN local area network
  • WAN wide area network
  • Wi-Fi wireless network
  • Bluetooth wireless network
  • mobile communication network such as Bluetooth
  • RF radio frequency
  • GPS global positioning system
  • ultra-wideband or pulse radio any other suitable communication network, or any combination thereof.
  • Other suitable network types and configurations will be apparent
  • the mobile computing device (600) can also include a memory (602) (for example, random access memory, read-only memory, etc.).
  • the memory (602) can be read from and/or written to in a well-known manner.
  • the memory (602) can be non-transitory computer readable recording media.
  • Data stored in the mobile computing device (600) can be stored on any type of suitable computer readable media, such as optical storage (for example, a compact disc, digital versatile disc, Blu-ray disc, etc.), magnetic tape storage (for example, a hard disk drive), or solid-state drive.
  • An operating system (610) and one or more applications (612) can be stored in the memory (602).
  • the data can be configured in any type of suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc.
  • suitable configurations and storage types will be apparent to persons having skill in the relevant art.
  • the mobile computing device (600) can also include a communications interface (614).
  • the communications interface (614) can be configured to allow software and data to be transferred between the mobile computing device (600) and external or remote devices.
  • the communications interface (614) can include a cellular phone interface, modem, a network interface (for example, an Ethernet card), a communications port, a PCMCIA slot and card, etc.
  • Software and data transferred via the communications interface (614) can be in the form of signals, which may be electronic, electromagnetic, optical, or other signals as will be apparent to persons having skill in the relevant art.
  • the signals may travel via Wi-Fi, wire, cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, etc.
  • Computer executable instructions can be stored in the memory (602). Part or all of the computer executable instructions (for example, part or all of the computer executable instructions in the form of a downloadable app) can be received via the communications interface (614). Such computer executable instructions, when executed, can enable the mobile computing device (600) to implement the present methods (for example, token management operations) as discussed herein. Computer executable instructions can include controllers of the mobile computing device (600). Where the present disclosure is implemented using software, the software can be stored in a computer program product or non-transitory computer readable medium and loaded into the mobile computing device (600) using a removable storage drive or communications interface (614).
  • the mobile computing device (600) can also include various hardware devices, such as a camera (620), a microphone (not shown), a power controller (622), a peripheral interface (624), and input/output ports (626) such as USB, firewire, thunderbolt ports, etc.
  • various hardware devices such as a camera (620), a microphone (not shown), a power controller (622), a peripheral interface (624), and input/output ports (626) such as USB, firewire, thunderbolt ports, etc.
  • the mobile computing device (600) can also include a display interface (616) that outputs display signals to a display unit (618), for example, LCD screen, plasma screen, LED screen, DLP screen, CRT screen, or other suitable display device as desired.
  • a display unit (618) can comprise a touch screen capability for input.
  • the operating system(s) (610) of the mobile computing device (600) can communicate with either the serial buses (vis-à-vis the communication infrastructure (608) directly, if running the operating system (610) as a native operating system or as a pass-through from the hypervisor (not shown), if running on a guest virtual machine.
  • the operating system(s) (610) can control access to device hardware and device power states using the defined policy rules. Access to one or more applications (612) and one or more files stored or running on the operating system(s) (610) are also enabled or disabled using the device management functionality of the location-based security system and method of the present disclosure.
  • a file can be, for example, a document, picture, video, database records, etc.
  • the operating system(s) (610) can include a mobile operating system, for example, an Android mobile operating system, a Wear mobile operating system, a Chrome mobile operating system, a Sailfish mobile operating system, a Tizen mobile operating system, a KaiOS mobile operating system, a Fuchsia mobile operating system, a LiteOS mobile operating system, an OpenHarmony mobile operating system, an Ubuntu mobile operating system, an iOS mobile operating system, an iPadOS mobile operating system, a watchOS mobile operating system, a bridgeOS mobile operating system, a Kindle mobile operating system, a Nintendo mobile operating system, a PlayStation mobile operating system, or a Windows mobile operating system.
  • a mobile operating system for example, an Android mobile operating system, a Wear mobile operating system, a Chrome mobile operating system, a Sailfish mobile operating system, a Tizen mobile operating system, a KaiOS mobile operating system, a Fuchsia mobile operating system, a LiteOS mobile operating system, an OpenHarmony mobile operating system, an Ubuntu mobile operating system, an iOS mobile operating system, an iPad
  • the mobile computing device (600) includes the memory (602) having computer-readable instructions tangibly recorded thereon.
  • the mobile computing device (600) can also include a hardware processor (606) configured to execute the computer-readable instructions recorded on the memory (602).
  • the memory (602) can be in the form of a hard disk, optical disk, flash memory (for example, EEPROM, SSN, NAND), or any other suitable memory device including memory chips as desired.
  • the memory (602) can include one or more devices having addressable locations for storing data related to applications, software, and information, and/or data related to software and hardware components of the mobile computer device.
  • a client system device (702) can include one or more processors (704) and a system memory (706).
  • a memory bus (760) can be used for communicating between one or more processors (704) and system memory (706).
  • the one or more processors (704) can be of any type including but not limited to a microprocessor ( ⁇ P), a microcontroller ( ⁇ C), a digital signal processor (DSP), or any combination thereof.
  • the one or more processors (704) can include one more levels of caching, such as a level-one cache (708) and a level-two cache (710), a processor core (712), and registers (714).
  • An example processor core (712) can include an arithmetic logic unit (ALU), a floating-point unit (FPU), a digital signal processing core (DSP Core), or any combination thereof.
  • a memory controller (758) can also be used with the one or more processors (704), or in some implementations, memory controller (758) can be an internal part of the one or more processors (704).
  • system memory (706) can be of any type including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.) or any combination thereof.
  • the system memory (706) can include an operating system (716), one or more applications (718), and program data (720).
  • the system architecture (700) can have additional features or functionality, and additional interfaces to facilitate communications between the client system device (702) and any other devices and interfaces.
  • a bus/interface controller (722) can be used to facilitate communications between the client system device (702) and one or more data storage devices (724) via a storage interface bus (726).
  • the data storage devices (724) can be removable storage devices (728), non-removable storage devices (730), or a combination thereof. Examples of removable storage and non-removable storage devices include magnetic disk devices such as flexible disk drives and hard-disk drives (HDD), optical disk drives such as compact disk (CD) drives or digital versatile disk (DVD) drives, solid state drives (SSD), and tape drives to name a few.
  • Example computer storage media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.
  • the system memory (706), removable storage devices (728), and non-removable storage devices (730) are examples of computer readable storage media.
  • Computer readable storage media include, but not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media which can be used to store the desired information and which can be accessed by client system device (702). Any such computer readable storage media can be a part of system architecture (700).
  • the system architecture (700) can also include an interface bus (732) for facilitating communication from various interface devices (for example, output devices (734), peripheral interfaces (736), and communication devices (738)) to the client system device (702) via bus/interface controller (722).
  • Example output devices (734) include a graphics processing unit (740) and an audio processing unit (742), which can be configured to communicate to various external devices such as a display or speakers via one or more A/V ports (744).
  • Example peripheral interfaces (736) include a serial interface controller (746) or a parallel interface controller (748), which can be configured to communicate with external devices such as input devices (for example, keyboard, mouse, pen, voice input device, touch input device, etc.) or other peripheral devices (for example, printer, scanner, etc.) via one or more I/O ports (750).
  • Communication devices (738) can include a network controller (752), which can be arranged to facilitate communications with one or more other architectures (754) over a network communication link via one or more communication ports (756).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
EP23199668.7A 2022-11-16 2023-09-26 Systèmes et procédés sécurisés pour jetons numériques Pending EP4372585A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US17/988,533 US20240163276A1 (en) 2022-11-16 2022-11-16 Secure systems and methods for digital tokens

Publications (1)

Publication Number Publication Date
EP4372585A1 true EP4372585A1 (fr) 2024-05-22

Family

ID=88196984

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23199668.7A Pending EP4372585A1 (fr) 2022-11-16 2023-09-26 Systèmes et procédés sécurisés pour jetons numériques

Country Status (2)

Country Link
US (1) US20240163276A1 (fr)
EP (1) EP4372585A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210051012A1 (en) * 2018-03-07 2021-02-18 Visa International Service Association Secure remote token release with online authentication
WO2021222398A1 (fr) * 2019-05-02 2021-11-04 Ares Technologies, Inc. Systèmes et procédés d'autorisation cryptographique de communications sans fil

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8266684B2 (en) * 2008-09-30 2012-09-11 General Instrument Corporation Tokenized resource access
US8819848B2 (en) * 2009-11-24 2014-08-26 Comcast Interactive Media, Llc Method for scalable access control decisions
US9819672B1 (en) * 2015-06-26 2017-11-14 EMC IP Holding Company LLC Sharing access tokens with trusted users
US10225084B1 (en) * 2015-12-29 2019-03-05 EMC IP Holding Company LLC Method, apparatus and computer program product for securely sharing a content item
EP3408987B1 (fr) * 2016-01-29 2019-11-06 Google LLC Authentification de dispositif local
WO2020123926A1 (fr) * 2018-12-13 2020-06-18 Login Id Inc. Systèmes informatiques décentralisés et procédés pour effectuer des actions à l'aide de données privées stockées
US10735198B1 (en) * 2019-11-13 2020-08-04 Capital One Services, Llc Systems and methods for tokenized data delegation and protection
US20210392003A1 (en) * 2020-06-12 2021-12-16 Login Id Inc. Decentralized computing systems and methods for performing actions using stored private data
GB2599066A (en) * 2020-07-22 2022-03-30 Arqit Ltd Quantum-safe payment system
WO2022051267A1 (fr) * 2020-09-01 2022-03-10 Sigma Computing, Inc. Génération d'index d'entrepôt de données
US20220138298A1 (en) * 2020-11-05 2022-05-05 Login Id Inc. Device and systems for strong identity and strong authentication
US20230120534A1 (en) * 2021-08-29 2023-04-20 Artema Labs, Inc Methods for Conditional Transaction Tokens, Secure Sharing of Token Assets, Wallet Spam Protection, and User Interfaces for Acceptance of Terms
WO2023154436A1 (fr) * 2022-02-11 2023-08-17 Lith Llc Génération et maintien de jetons numériques sur une chaîne de blocs à l'aide d'identifiants de dispositif physique

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210051012A1 (en) * 2018-03-07 2021-02-18 Visa International Service Association Secure remote token release with online authentication
WO2021222398A1 (fr) * 2019-05-02 2021-11-04 Ares Technologies, Inc. Systèmes et procédés d'autorisation cryptographique de communications sans fil

Also Published As

Publication number Publication date
US20240163276A1 (en) 2024-05-16

Similar Documents

Publication Publication Date Title
US12095746B2 (en) Secure multi-party protocol
US11671425B2 (en) Cross-region requests
US11899820B2 (en) Secure identity and profiling system
US11528263B2 (en) Using keys with targeted access to the blockchain to verify and authenticate identity
US10680827B2 (en) Asymmetric session credentials
JP6941183B2 (ja) データのトークン化
US10182044B1 (en) Personalizing global session identifiers
US10277569B1 (en) Cross-region cache of regional sessions
WO2020133346A1 (fr) Partage de données
US20150120569A1 (en) Virtual currency address security
KR20210040078A (ko) 안전한 보관 서비스를 위한 시스템 및 방법
US20130073854A1 (en) Data storage incorporating crytpographically enhanced data protection
CN110445840B (zh) 一种基于区块链技术的文件存储和读取的方法
US11436351B1 (en) Homomorphic encryption of secure data
US20240048361A1 (en) Key Management for Cryptography-as-a-service and Data Governance Systems
US10812267B2 (en) Secure password lock and recovery
EP4372585A1 (fr) Systèmes et procédés sécurisés pour jetons numériques
CN113672973B (zh) 基于可信执行环境的risc-v架构的嵌入式设备的数据库系统
US20240048380A1 (en) Cryptography-as-a-Service
US20240048532A1 (en) Data exchange protection and governance system
WO2024030308A1 (fr) Système de protection et de gouvernance d'échange de données
CN118468334A (zh) 一种用户隐私鉴别方法、系统、设备和存储介质
CN118869243A (zh) 一种区块链隐私数据共享方法及其系统

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR