US20120324225A1 - Certificate-based mutual authentication for data security - Google Patents
Certificate-based mutual authentication for data security Download PDFInfo
- Publication number
- US20120324225A1 US20120324225A1 US13/527,867 US201213527867A US2012324225A1 US 20120324225 A1 US20120324225 A1 US 20120324225A1 US 201213527867 A US201213527867 A US 201213527867A US 2012324225 A1 US2012324225 A1 US 2012324225A1
- Authority
- US
- United States
- Prior art keywords
- client
- api
- access
- server
- constraints
- 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.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims abstract description 32
- 230000002123 temporal effect Effects 0.000 claims abstract description 10
- 238000012795 verification Methods 0.000 claims abstract description 6
- 238000013475 authorization Methods 0.000 abstract description 18
- 238000005516 engineering process Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000036541 health Effects 0.000 description 2
- 239000000344 soap Substances 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000003339 best practice Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 238000010926 purge Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
- G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
Definitions
- the following disclosure relates generally to data security applications and, more particularly, to systems and methods for maintaining data security using certificate-based mutual authentication.
- Data encryption uses an encryption key to encrypt the sensitive data.
- the resulting encrypted data sometimes called cipher text, can be stored in a database.
- the encrypted data is generally larger than the original value, requiring more space. Storing the encryption key in the same place exposes the encrypted data to easy decryption if the database is compromised.
- Another layer of security is sometimes provided in the form a token that represents or acts as a pointer to the encrypted data.
- Most existing token-based solutions require a centralized implementation with a single data store in order to minimize the risk of token collision, and to ensure a one-to-one relationship between a token and the sensitive data it represents.
- a method of protecting sensitive data from unauthorized access includes the computer-implemented steps of: (1) establishing a plurality of client roles for authorizing access to a set of API functions; (2) establishing a plurality of API keys for authorizing access to a subset of the set of API functions; (3) establishing one or more constraints for limiting access to the subset of the set of API functions, the constraints comprising one or more temporal constraints, one or more volume constraints, and an end user identity filter; (4) assigning a first client role and a first API key to a first client; (5) receiving from the first client, at a first server, a request for access to a protected API function; (6) requiring the mutual exchange and verification of certificates between the first client and the first server; and (7) allowing the request if both the first client role and the first API key authorize access to the protected API function, while also limiting the access by imposing one or more of the one or more constraints.
- the one or more temporal constraints is a time-related limit selected from the group consisting of UTC clock time, client's local time of day, server's local time of day, client's local day of the week, and server's local day of the week.
- the one or more volume constraints comprises a limit on the quantity of requests by the first client within a predetermined time window.
- the end user identity filter comprises a rule permitting the display of masked values only unless an identified end user making the request matches a name on an approved user list.
- FIG. 1 is an exemplary system architecture diagram, according to particular embodiments.
- FIG. 2A is an illustration of sensitive data and a corresponding token, according to particular embodiments.
- FIG. 2B is an illustration of sensitive data and a corresponding token, according to particular embodiments.
- FIG. 3 is a diagram of an exemplary authentication system, according to particular embodiments.
- Ranges can be expressed herein as from “about” one particular value, and/or to “about” another particular value. When such a range is expressed, another aspect includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the particular value forms another aspect. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint.
- the terms “optional” or “optionally” mean that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.
- aspects of this disclosure relate to systems and methods for protecting and using sensitive data such as credit card numbers in compliance with regulations and best practices.
- sensitive data such as credit card numbers in compliance with regulations and best practices.
- the systems and methods are described herein primarily within the context of credit card numbers, the technology described herein is useful and applicable for protecting any type of sensitive data, such as social security numbers, passport numbers, license numbers, account numbers, payroll data, national health insurance numbers, personally-identifiable information (PII) such as name and date of birth, and the like.
- PII personally-identifiable information
- FIG. 1 illustrates the architecture for an exemplary system 100 , according to particular embodiments.
- the system 100 as shown includes four distinct modules: a token manager 110 , a key manager 120 , a data vault 130 , and a client/application 140 .
- the key manager 120 manages encryption keys that are used to encrypt sensitive data and permit only authorized users to reveal or otherwise access the sensitive data.
- the encryption keys may be distributed to the token manager 110 for use in encryption and decryption functions.
- the token manager 110 is a central part of the system 100 , providing tokenization, encryption, client management, event logging, and administrative functions. Tokenization describes the process of receiving sensitive data and generating a token to be used in its place.
- the token manager 110 generates the token, encrypts the original sensitive data, and stores the encrypted data (cipher text) in the data vault 130 .
- the encrypted data is stored only in the data vault 130 .
- the token is a reference to the encrypted data; there is no mathematical relationship between a token and the encrypted data. Therefore, the token may be safely used throughout the system 100 , while the encrypted data it represents remains stored in the data vault 130 .
- the token manager 110 ensures that there is a one-to-one relationship between the sensitive data and the generated token, so that referential integrity is maintained throughout the system 100 .
- the data vault 130 is a depository such as a database for storing the tokens and the encrypted data.
- the data vault does not store the encryption key, which is stored and controlled using the key manager 120 .
- the data vault 130 may store a key profile number or other pointer that indicates which key was used to encrypt the data.
- the token manager 110 may use a data access technology such as JDBC (Java Database Connectivity) to communicate with the data vault 130 .
- JDBC Java Database Connectivity
- the client or application 140 may be any of a variety of applications or platforms involved in the collection, handling, or processing of sensitive data.
- the client/application 140 may be a financial application for processing or analyzing payments received by a business enterprise.
- Another client/application 140 may be a point-of-sale device such as a cash register or payment card reader.
- integration of client/applications 140 may be accomplished through SOAP/web services.
- any application 140 that supports web services can be integrated with the token manager 110 and may be configured to make calls to tokenize/encrypt sensitive data or, if authorized, to decrypt/access the sensitive data.
- the system 100 may include other modules depending on the implementation.
- the system 100 may include a directory 150 includes a database for storing any type of data useful in the system 100 .
- the directory 150 may include client IP addresses, hostnames, user identities, client role definitions, client permissions and data access policies, and the like.
- the token manager 110 may use LDAP or another protocol for accessing and maintaining the directory 150 .
- the system 100 may also include an administrator 152 with access to the token manager 110 .
- the administrator 152 may use HTTP/S or another secure protocol for communicating with the token manager 110 .
- the token manager 110 and the key manager 120 may be configured to generate security event messages via Syslog. These logs can be directed to an event log 154 which may include an event management application (SIEM) for logging, collecting, storing, analyzing, and/or reporting events.
- SIEM event management application
- the token manager 110 may also be configured to send e-mail alerts using an e-mail server 156 via SMTP or similar protocol.
- the system 100 may also include a metadata store 158 .
- the token manager 110 receives sensitive data from an application 140 along with a request to protect it, generates a token, and inserts the token in place of the sensitive data.
- the key manager 120 supplies an encryption key to the token manager 110 , which then encrypts the sensitive data and stores the encrypted data (cipher text) in the data vault 130 .
- Tokens can be used safely in any application or database without exposing the sensitive data.
- the application 140 transmits a request (by web services call, for example) to the token manager 110 and presents the token.
- the token manager 110 validates the credentials of the requesting application and, if authorized, looks-up the token in the data vault 130 , identifies the matching cipher text, decrypts the cipher text, and returns the original sensitive data back to the application 140 .
- the system 100 ensures a one-to-one relationship between a token and the sensitive data it represents.
- the data vault 130 contains a single encrypted version of each original sensitive data. Even when encryption keys change over time, there is only one instance of the encrypted value stored in the data vault 130 . In use, this means that the returned token will consistently represent the same original data throughout the system 100 , in different applications and across multiple data sets.
- the token manager 110 in particular embodiments may be configured to generate a token that is structurally similar in length and format to that of the original sensitive data.
- a token 200 a can be formatted to preserve any number of leading and trailing characters found in the original sensitive data 10 .
- the head 202 a includes the leading six characters
- the tail 206 a includes the trailing four
- the body 204 a includes tokenized characters.
- a token 200 b can be formatted to preserve both the length and the data type (alpha or numeric, and the like) of the original sensitive data 10 .
- the head 202 b includes the leading six characters
- the body 204 b includes six numeric characters
- the tail 206 b includes the trailing four characters. Any number (including zero) of the leading and/or trailing characters from the original sensitive data 10 may be preserved.
- the format-preserving tokenization process is also described in the commonly owned and co-pending U.S. patent application Ser. No. 13/040,133, entitled “System and Methods for Format Preserving Tokenization of Sensitive Information,” which is herein incorporated by reference in its entirety.
- the task of generating a token may be accomplished in one or more steps performed by a token generation algorithm.
- the token generation algorithm may be configured to generate a token that is independent of at least a portion of the data in a sensitive data string.
- the token manager 110 in particular embodiments requires authentication at multiple levels in order to provide secure access control.
- the administrator 152 in particular embodiments manages client authentication and authorization through the creation, control, and maintenance of Clients, Client Roles, API Keys, and Mutual Authentication.
- a Client accesses the services provided by the token manager 110 or other server through SOAP/web services API calls.
- the administrator 152 may create client identities, including the client's IP address/hostname and other identifying characteristics.
- the administrator 152 may enable or disable a Client at any time via the management console for any reason; for example, to protect sensitive data.
- a Client 140 a requests access to the services provided by the token manager or other server 110 a.
- All Clients are assigned to a Client Role.
- a Client can only belong to a single Client Role; however, a Client Role may include multiple Clients.
- Client Roles are used to defines the rights and restrictions of all the member Clients. Because the creation of authorization policies is done at the Client Role level, rather than at the Client level, administration of those policies is simplified (even for a large number of Clients and Client Roles). Every member Client is bound by the rules of the Client Role. For example, a Client Role may be established for the Finance Department of a business enterprise, with permissions granted to access a particular set of API functions. All Clients associated with any applications used by the Finance Department would be assigned to this Client Role.
- An API Application Programming Interface
- An API may include routines, data structures, object classes, variables, and the like.
- the token manager described herein may include API functions such as protect (i.e., protect sensitive data using encryption and/or tokenization), protect bulk (i.e., multiple items of sensitive data in a set), reveal (i.e., decrypt and expose the sensitive data), reveal bulk, send to wastebasket, send to wastebasket bulk, retrieve from wastebasket, retrieve from wastebasket bulk, empty wastebasket, purge tokens, and lookup.
- An API key is a random string that is known to both the Client and the token manager or other server providing resources.
- the Client When calling an API function, the Client must provide the correct API Key.
- Authorization based on API Keys can help differentiate permissions between multiple Clients coming from the same host and/or multiple Clients being passed through a proxy service.
- a number of API Keys must be established for the Finance Department.
- an API Key for a finance application should allow access to only those API functions that are called by that finance application.
- a separate API Key for an auditing application should allow access to only those API functions that are called by the auditing application. In this way, the API Keys provide another level of granularity to the client authorization process.
- API Keys are used in tandem with Client Roles; in other words, the Client must have permission from both its Client Role and its API Key in order to access a given API function on a token manager or other server. If the Client does not present both a Client Role permission and a valid API Key, the Client's request will be rejected.
- a Client Role may be established for point-of-sale devices. Client processes and applications assigned to this Client Role may be given authorization to “protect” and to “reveal” sensitive data (such as a credit card number). Certain types of users of the point-of-sale devices may be further controlled by using API Keys.
- a teller for example, may be assigned an API Key that authorizes access to only the “protect” API function.
- a store manager may be assigned a different API Key, for example, that authorizes access to both the “protect” and “reveal” API functions.
- a teller using a point-of-sale device who attempts to access the “reveal” API and thereby obtain sensitive data, such as a credit card number
- a store manager can use the same point-of-sale device and will be allowed to access the “reveal” API function because her API Key allows it (to process a refund, for example).
- Authorization policies are customizable for each Client Role by the administrator 152 .
- the administrator 152 can establish, revise, and update a wide variety of permissions and constraints. For example, the administrator 152 can assign a Client to a particular Client Role.
- the administrator 152 can vary the API functions to which a Client Role has access.
- the administrator 152 can establish the types of data allowed for access or presentation to certain Clients.
- Client role authorization can also be used to create permissions based on IP address, a range of IP addresses, hostname, and the like.
- Temporal constraints may include the UTC clock time, the local time of day (at the client, server, or another location), the day of the week, the day of the month, week of the year, quarter of the year, or any other time- or date-based limitation.
- the local time of day and/or day of the week can be particularly useful in retail and other settings where the hours of operation (for retail and other processing operations) are generally known.
- a teller may be authorized only during retail hours, whereas a payment processor may be authorized during overnight hours.
- Authorizations may also include volume constraints, such as a limit on the number of API calls made from a particular device or during a certain time window.
- a request to access and use the “reveal” API function (which exposes sensitive data, such as a credit card number) in particular embodiments requires confirmation of the end user's personal identity.
- User-level authorizations can determine if sensitive data should be returned as clear text or as partially masked text (masking digits with asterisks, for example).
- the tools described herein for client access and authentication may be supported by information in the directory 150 (shown in FIG. 1 ) which, in particular embodiments, may be accessed using LDAP or another suitable protocol.
- the management console used by the administrator 152 may include access to the directory 150 in order to create, read, update, or delete information about Clients such as IP addresses and hostnames, Client Role definitions and authorization policies, API Keys, end user identities, certificates and keys, and the like.
- FIG. 3 is a diagram illustrating an exemplary mutual authentication system 300 , according to particular embodiments.
- the Server 110 a may be a token manager or other server configured to provide resources to one or more Clients 140 a .
- a trust store 350 is a repository for storing the public key portion of a cryptographic system that requires two separate keys; a public key and a private key.
- RSA is an algorithm often used in two-key cryptography. The keys correspond to trusted entities.
- the client key store 360 is a repository for storing the client's private key 362 .
- the server key store 370 is a repository for storing the server's private key 374 .
- FIG. 3 illustrates the steps involved in a mutual authentication, according to particular embodiments.
- the Client 140 a sends a request to a Server 110 a for a protected resource.
- the Server presents its certificate (Step 302 ).
- the Client accesses the trust store 350 to retrieve the server's public key 354 and thereby verify the server's certificate.
- the Client 140 a presents its own certificate to the server (Step 304 ).
- the Server accesses the trust store 350 to retrieve the client's public key 352 and thereby verify the client's certificate.
- a method of protecting sensitive data includes the step of establishing a plurality of Client Roles for authorizing access to a set of API functions, establishing a plurality of API Keys for authorizing access to a subset of the set of API functions, establishing one or more constraints for limiting access to the subset, and requiring the mutual exchange and verification of certificates between the client and server before a request for access is allowed.
- the Client Roles include a number of parameters defining the scope and authority of member Clients.
- the API Keys include a number of parameters further defining the scope and authority of Clients and applications that request access to certain API functions; typically, a subset of the set of API functions authorized at the Client Role level.
- the additional constraints may include one or more temporal constraints, imposed either alone or in combination.
- a volume constraint may include a limit on the number of requests made from a particular device, or during a predetermined time window, such as a range of hours, a entire day, or a particular day of the week.
- An end user constraint may include an end user identity filter. If an identified end user's name is found on an approved user list, then access to the requested API function may be unlimited; otherwise, access is limited according to the user's identity. For example, for an approved end user, an API function may return sensitive data in the form of clear text, whereas an unapproved user may only be shown partially masked text.
- Any of the client authorization techniques, together with the mutual authentication regimen, may be combined in a method of protecting sensitive data.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mathematical Physics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Storage Device Security (AREA)
Abstract
Description
- This application claims the benefit of and priority to U.S. Provisional Application No. 61/499,121, entitled “Token Manager for Data Protection,” filed Jun. 20, 2011, which is herein incorporated by reference in its entirety.
- The following disclosure relates generally to data security applications and, more particularly, to systems and methods for maintaining data security using certificate-based mutual authentication.
- The proliferation of business-critical and sensitive electronic data creates a data security challenge, especially when sensitive data is collected in geographically distant locations and stored in multiple applications and databases for later processing.
- Data encryption uses an encryption key to encrypt the sensitive data. The resulting encrypted data, sometimes called cipher text, can be stored in a database. The encrypted data is generally larger than the original value, requiring more space. Storing the encryption key in the same place exposes the encrypted data to easy decryption if the database is compromised.
- Another layer of security is sometimes provided in the form a token that represents or acts as a pointer to the encrypted data. Most existing token-based solutions require a centralized implementation with a single data store in order to minimize the risk of token collision, and to ensure a one-to-one relationship between a token and the sensitive data it represents.
- Protecting sensitive data from unauthorized disclosure is a significant challenge, especially in computing environments with a large number and variety of client applications, devices, and end users. Increasingly complex systems require continuing advancement in the area of client access authorization and control.
- A method of protecting sensitive data from unauthorized access, according to various embodiments, includes the computer-implemented steps of: (1) establishing a plurality of client roles for authorizing access to a set of API functions; (2) establishing a plurality of API keys for authorizing access to a subset of the set of API functions; (3) establishing one or more constraints for limiting access to the subset of the set of API functions, the constraints comprising one or more temporal constraints, one or more volume constraints, and an end user identity filter; (4) assigning a first client role and a first API key to a first client; (5) receiving from the first client, at a first server, a request for access to a protected API function; (6) requiring the mutual exchange and verification of certificates between the first client and the first server; and (7) allowing the request if both the first client role and the first API key authorize access to the protected API function, while also limiting the access by imposing one or more of the one or more constraints.
- In another aspect of the method, the one or more temporal constraints is a time-related limit selected from the group consisting of UTC clock time, client's local time of day, server's local time of day, client's local day of the week, and server's local day of the week. The one or more volume constraints comprises a limit on the quantity of requests by the first client within a predetermined time window. The end user identity filter comprises a rule permitting the display of masked values only unless an identified end user making the request matches a name on an approved user list.
- Having thus described various embodiments in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
-
FIG. 1 is an exemplary system architecture diagram, according to particular embodiments. -
FIG. 2A is an illustration of sensitive data and a corresponding token, according to particular embodiments. -
FIG. 2B is an illustration of sensitive data and a corresponding token, according to particular embodiments. -
FIG. 3 is a diagram of an exemplary authentication system, according to particular embodiments. - The present systems and apparatuses and methods are understood more readily by reference to the following detailed description, examples, drawing, and claims, and their previous and following descriptions. However, before the present devices, systems, and/or methods are disclosed and described, it is to be understood that this invention is not limited to the specific devices, systems, and/or methods disclosed unless otherwise specified, as such can, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting.
- The following description is provided as an enabling teaching in its best, currently known embodiment. To this end, those skilled in the relevant art will recognize and appreciate that many changes can be made to the various aspects described herein, while still obtaining the beneficial results of the technology disclosed. It will also be apparent that some of the desired benefits can be obtained by selecting some of the features while not utilizing others. Accordingly, those with ordinary skill in the art will recognize that many modifications and adaptations are possible, and may even be desirable in certain circumstances, and are a part of the invention described. Thus, the following description is provided as illustrative of the principles of the invention and not in limitation thereof.
- As used throughout, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a” component can include two or more such components unless the context indicates otherwise.
- Ranges can be expressed herein as from “about” one particular value, and/or to “about” another particular value. When such a range is expressed, another aspect includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the particular value forms another aspect. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint.
- As used herein, the terms “optional” or “optionally” mean that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.
- Aspects of this disclosure relate to systems and methods for protecting and using sensitive data such as credit card numbers in compliance with regulations and best practices. Although the systems and methods are described herein primarily within the context of credit card numbers, the technology described herein is useful and applicable for protecting any type of sensitive data, such as social security numbers, passport numbers, license numbers, account numbers, payroll data, national health insurance numbers, personally-identifiable information (PII) such as name and date of birth, and the like.
-
FIG. 1 illustrates the architecture for anexemplary system 100, according to particular embodiments. Thesystem 100 as shown includes four distinct modules: atoken manager 110, akey manager 120, adata vault 130, and a client/application 140. - The
key manager 120 manages encryption keys that are used to encrypt sensitive data and permit only authorized users to reveal or otherwise access the sensitive data. The encryption keys may be distributed to thetoken manager 110 for use in encryption and decryption functions. - The
token manager 110 is a central part of thesystem 100, providing tokenization, encryption, client management, event logging, and administrative functions. Tokenization describes the process of receiving sensitive data and generating a token to be used in its place. Thetoken manager 110 generates the token, encrypts the original sensitive data, and stores the encrypted data (cipher text) in thedata vault 130. The encrypted data is stored only in thedata vault 130. The token is a reference to the encrypted data; there is no mathematical relationship between a token and the encrypted data. Therefore, the token may be safely used throughout thesystem 100, while the encrypted data it represents remains stored in thedata vault 130. Thetoken manager 110 ensures that there is a one-to-one relationship between the sensitive data and the generated token, so that referential integrity is maintained throughout thesystem 100. - The
data vault 130 is a depository such as a database for storing the tokens and the encrypted data. The data vault does not store the encryption key, which is stored and controlled using thekey manager 120. In particular embodiments, thedata vault 130 may store a key profile number or other pointer that indicates which key was used to encrypt the data. Thetoken manager 110 may use a data access technology such as JDBC (Java Database Connectivity) to communicate with thedata vault 130. - The client or
application 140 may be any of a variety of applications or platforms involved in the collection, handling, or processing of sensitive data. For example, the client/application 140 may be a financial application for processing or analyzing payments received by a business enterprise. Another client/application 140 may be a point-of-sale device such as a cash register or payment card reader. In particular embodiments, integration of client/applications 140 may be accomplished through SOAP/web services. In this aspect, anyapplication 140 that supports web services can be integrated with thetoken manager 110 and may be configured to make calls to tokenize/encrypt sensitive data or, if authorized, to decrypt/access the sensitive data. - As illustrated in
FIG. 1 , thesystem 100 may include other modules depending on the implementation. For example, thesystem 100 may include adirectory 150 includes a database for storing any type of data useful in thesystem 100. For example, thedirectory 150 may include client IP addresses, hostnames, user identities, client role definitions, client permissions and data access policies, and the like. Thetoken manager 110 may use LDAP or another protocol for accessing and maintaining thedirectory 150. - The
system 100 may also include anadministrator 152 with access to thetoken manager 110. Theadministrator 152 may use HTTP/S or another secure protocol for communicating with thetoken manager 110. - The
token manager 110 and thekey manager 120 may be configured to generate security event messages via Syslog. These logs can be directed to anevent log 154 which may include an event management application (SIEM) for logging, collecting, storing, analyzing, and/or reporting events. - The
token manager 110 may also be configured to send e-mail alerts using ane-mail server 156 via SMTP or similar protocol. Thesystem 100 may also include ametadata store 158. - In use, the
token manager 110, according to particular embodiments, receives sensitive data from anapplication 140 along with a request to protect it, generates a token, and inserts the token in place of the sensitive data. Thekey manager 120 supplies an encryption key to thetoken manager 110, which then encrypts the sensitive data and stores the encrypted data (cipher text) in thedata vault 130. Tokens can be used safely in any application or database without exposing the sensitive data. - When an
application 140 or database requires the original sensitive data, theapplication 140 transmits a request (by web services call, for example) to thetoken manager 110 and presents the token. Thetoken manager 110 validates the credentials of the requesting application and, if authorized, looks-up the token in thedata vault 130, identifies the matching cipher text, decrypts the cipher text, and returns the original sensitive data back to theapplication 140. - According to particular embodiments, the
system 100 ensures a one-to-one relationship between a token and the sensitive data it represents. Thedata vault 130 contains a single encrypted version of each original sensitive data. Even when encryption keys change over time, there is only one instance of the encrypted value stored in thedata vault 130. In use, this means that the returned token will consistently represent the same original data throughout thesystem 100, in different applications and across multiple data sets. - The
token manager 110 in particular embodiments may be configured to generate a token that is structurally similar in length and format to that of the original sensitive data. For example, as shown inFIG. 2A , a token 200 a can be formatted to preserve any number of leading and trailing characters found in the original sensitive data 10. In the example shown, thehead 202 a includes the leading six characters, thetail 206 a includes the trailing four, and thebody 204 a includes tokenized characters. - As shown in
FIG. 2B , a token 200 b can be formatted to preserve both the length and the data type (alpha or numeric, and the like) of the original sensitive data 10. In the example shown, thehead 202 b includes the leading six characters, thebody 204 b includes six numeric characters, and thetail 206 b includes the trailing four characters. Any number (including zero) of the leading and/or trailing characters from the original sensitive data 10 may be preserved. The format-preserving tokenization process is also described in the commonly owned and co-pending U.S. patent application Ser. No. 13/040,133, entitled “System and Methods for Format Preserving Tokenization of Sensitive Information,” which is herein incorporated by reference in its entirety. - The task of generating a token may be accomplished in one or more steps performed by a token generation algorithm. As described above, the token generation algorithm may be configured to generate a token that is independent of at least a portion of the data in a sensitive data string.
- The
token manager 110 in particular embodiments requires authentication at multiple levels in order to provide secure access control. Referring again toFIG. 1 , theadministrator 152 in particular embodiments manages client authentication and authorization through the creation, control, and maintenance of Clients, Client Roles, API Keys, and Mutual Authentication. - Clients:
- A Client accesses the services provided by the
token manager 110 or other server through SOAP/web services API calls. Through a user interface called a management console, theadministrator 152 may create client identities, including the client's IP address/hostname and other identifying characteristics. Theadministrator 152 may enable or disable a Client at any time via the management console for any reason; for example, to protect sensitive data. Referring briefly toFIG. 3 , a Client 140 a requests access to the services provided by the token manager orother server 110 a. - Client Roles:
- All Clients are assigned to a Client Role. A Client can only belong to a single Client Role; however, a Client Role may include multiple Clients. Client Roles are used to defines the rights and restrictions of all the member Clients. Because the creation of authorization policies is done at the Client Role level, rather than at the Client level, administration of those policies is simplified (even for a large number of Clients and Client Roles). Every member Client is bound by the rules of the Client Role. For example, a Client Role may be established for the Finance Department of a business enterprise, with permissions granted to access a particular set of API functions. All Clients associated with any applications used by the Finance Department would be assigned to this Client Role.
- API Keys:
- An API (Application Programming Interface) is an interface that facilitates communication between various software components. An API may include routines, data structures, object classes, variables, and the like. In particular embodiments, for example, the token manager described herein may include API functions such as protect (i.e., protect sensitive data using encryption and/or tokenization), protect bulk (i.e., multiple items of sensitive data in a set), reveal (i.e., decrypt and expose the sensitive data), reveal bulk, send to wastebasket, send to wastebasket bulk, retrieve from wastebasket, retrieve from wastebasket bulk, empty wastebasket, purge tokens, and lookup.
- An API key is a random string that is known to both the Client and the token manager or other server providing resources. When calling an API function, the Client must provide the correct API Key. Authorization based on API Keys can help differentiate permissions between multiple Clients coming from the same host and/or multiple Clients being passed through a proxy service. Continuing the example above, a number of API Keys must be established for the Finance Department. For example, an API Key for a finance application should allow access to only those API functions that are called by that finance application. A separate API Key for an auditing application should allow access to only those API functions that are called by the auditing application. In this way, the API Keys provide another level of granularity to the client authorization process.
- API Keys are used in tandem with Client Roles; in other words, the Client must have permission from both its Client Role and its API Key in order to access a given API function on a token manager or other server. If the Client does not present both a Client Role permission and a valid API Key, the Client's request will be rejected.
- For example, a Client Role may be established for point-of-sale devices. Client processes and applications assigned to this Client Role may be given authorization to “protect” and to “reveal” sensitive data (such as a credit card number). Certain types of users of the point-of-sale devices may be further controlled by using API Keys. A teller, for example, may be assigned an API Key that authorizes access to only the “protect” API function. A store manager may be assigned a different API Key, for example, that authorizes access to both the “protect” and “reveal” API functions. In use, a teller using a point-of-sale device who attempts to access the “reveal” API (and thereby obtain sensitive data, such as a credit card number) will be rejected. A store manager, however, can use the same point-of-sale device and will be allowed to access the “reveal” API function because her API Key allows it (to process a refund, for example).
- Client Role Authorization Policies:
- Authorization policies are customizable for each Client Role by the
administrator 152. Theadministrator 152 can establish, revise, and update a wide variety of permissions and constraints. For example, theadministrator 152 can assign a Client to a particular Client Role. Theadministrator 152 can vary the API functions to which a Client Role has access. Theadministrator 152 can establish the types of data allowed for access or presentation to certain Clients. Client role authorization can also be used to create permissions based on IP address, a range of IP addresses, hostname, and the like. - Authorizations may be based on temporal constraints, imposed alone or in combination with others. Temporal constraints, for example, may include the UTC clock time, the local time of day (at the client, server, or another location), the day of the week, the day of the month, week of the year, quarter of the year, or any other time- or date-based limitation. The local time of day and/or day of the week can be particularly useful in retail and other settings where the hours of operation (for retail and other processing operations) are generally known. A teller may be authorized only during retail hours, whereas a payment processor may be authorized during overnight hours.
- Authorizations may also include volume constraints, such as a limit on the number of API calls made from a particular device or during a certain time window.
- End User Identity:
- A request to access and use the “reveal” API function (which exposes sensitive data, such as a credit card number) in particular embodiments requires confirmation of the end user's personal identity. User-level authorizations can determine if sensitive data should be returned as clear text or as partially masked text (masking digits with asterisks, for example).
- Certificate-Based Mutual Authentication,
- as described more fully below, involves a mutual exchange of certificates between Client 140 a and
Server 110 a, in particular embodiments, before the Server will grant access to the API functions or other protected resources provided by the Server. - The tools described herein for client access and authentication may be supported by information in the directory 150 (shown in
FIG. 1 ) which, in particular embodiments, may be accessed using LDAP or another suitable protocol. The management console used by theadministrator 152 may include access to thedirectory 150 in order to create, read, update, or delete information about Clients such as IP addresses and hostnames, Client Role definitions and authorization policies, API Keys, end user identities, certificates and keys, and the like. -
FIG. 3 is a diagram illustrating an exemplarymutual authentication system 300, according to particular embodiments. TheServer 110 a may be a token manager or other server configured to provide resources to one or more Clients 140 a. A trust store 350 is a repository for storing the public key portion of a cryptographic system that requires two separate keys; a public key and a private key. RSA is an algorithm often used in two-key cryptography. The keys correspond to trusted entities. - The client
key store 360 is a repository for storing the client'sprivate key 362. Theserver key store 370 is a repository for storing the server'sprivate key 374. -
FIG. 3 illustrates the steps involved in a mutual authentication, according to particular embodiments. First, inStep 301, the Client 140 a sends a request to aServer 110 a for a protected resource. In response the Server presents its certificate (Step 302). InStep 303, the Client accesses the trust store 350 to retrieve the server'spublic key 354 and thereby verify the server's certificate. Next, the Client 140 a presents its own certificate to the server (Step 304). InStep 305, the Server accesses the trust store 350 to retrieve the client'spublic key 352 and thereby verify the client's certificate. These verification steps accomplished by both Client and Server make this a mutual authentication system. Once the mutual authentication is completed, the Client may access the protected resources offered by the Server (Step 306). - In particular embodiments, the token manager or
other Server 110 a requires both client authorization and mutual authentication before permitting client access. In one embodiment, at the server level, a method of protecting sensitive data includes the step of establishing a plurality of Client Roles for authorizing access to a set of API functions, establishing a plurality of API Keys for authorizing access to a subset of the set of API functions, establishing one or more constraints for limiting access to the subset, and requiring the mutual exchange and verification of certificates between the client and server before a request for access is allowed. - The Client Roles, as described herein, include a number of parameters defining the scope and authority of member Clients. At a more granular level, the API Keys include a number of parameters further defining the scope and authority of Clients and applications that request access to certain API functions; typically, a subset of the set of API functions authorized at the Client Role level.
- The additional constraints may include one or more temporal constraints, imposed either alone or in combination. A volume constraint may include a limit on the number of requests made from a particular device, or during a predetermined time window, such as a range of hours, a entire day, or a particular day of the week. An end user constraint may include an end user identity filter. If an identified end user's name is found on an approved user list, then access to the requested API function may be unlimited; otherwise, access is limited according to the user's identity. For example, for an approved end user, an API function may return sensitive data in the form of clear text, whereas an unapproved user may only be shown partially masked text.
- Any of the client authorization techniques, together with the mutual authentication regimen, may be combined in a method of protecting sensitive data.
- Although the systems and methods are described herein primarily within the context of numerical data such as credit card numbers, the technology described herein is useful and applicable for protecting any type of sensitive data, such as social security numbers, passport numbers, license numbers, account numbers, payroll data, national health insurance numbers, personally-identifiable information (PII) such as name and date of birth, and the like. Moreover, although several embodiments have been described herein, those of ordinary skill in art, with the benefit of the teachings of this disclosure, will understand and comprehend many other embodiments and modifications for this technology. The invention therefore is not limited to the specific embodiments disclosed or discussed herein, and that may other embodiments and modifications are intended to be included within the scope of the appended claims. Moreover, although specific terms are occasionally used herein, as well as in the claims or concepts that follow, such terms are used in a generic and descriptive sense only, and should not be construed as limiting the described invention or the claims that follow.
Claims (9)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/527,867 US20120324225A1 (en) | 2011-06-20 | 2012-06-20 | Certificate-based mutual authentication for data security |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161499121P | 2011-06-20 | 2011-06-20 | |
US13/527,867 US20120324225A1 (en) | 2011-06-20 | 2012-06-20 | Certificate-based mutual authentication for data security |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120324225A1 true US20120324225A1 (en) | 2012-12-20 |
Family
ID=47353665
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/527,867 Abandoned US20120324225A1 (en) | 2011-06-20 | 2012-06-20 | Certificate-based mutual authentication for data security |
US13/527,860 Abandoned US20120321078A1 (en) | 2011-06-20 | 2012-06-20 | Key rotation and selective re-encryption for data security |
US13/527,837 Active 2032-11-10 US8806204B2 (en) | 2011-06-20 | 2012-06-20 | Systems and methods for maintaining data security across multiple active domains |
US13/527,852 Expired - Fee Related US8812844B2 (en) | 2011-06-20 | 2012-06-20 | Luhn validation and data security across multiple active domains |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/527,860 Abandoned US20120321078A1 (en) | 2011-06-20 | 2012-06-20 | Key rotation and selective re-encryption for data security |
US13/527,837 Active 2032-11-10 US8806204B2 (en) | 2011-06-20 | 2012-06-20 | Systems and methods for maintaining data security across multiple active domains |
US13/527,852 Expired - Fee Related US8812844B2 (en) | 2011-06-20 | 2012-06-20 | Luhn validation and data security across multiple active domains |
Country Status (1)
Country | Link |
---|---|
US (4) | US20120324225A1 (en) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8689355B1 (en) * | 2011-08-30 | 2014-04-01 | Emc Corporation | Secure recovery of credentials |
US20140281480A1 (en) * | 2013-03-15 | 2014-09-18 | Vmware, Inc. | Systems and methods for providing secure communication |
US8972543B1 (en) * | 2012-04-11 | 2015-03-03 | Spirent Communications, Inc. | Managing clients utilizing reverse transactions |
US20150095160A1 (en) * | 2013-10-01 | 2015-04-02 | Paschar Llc | Method and system for providing advertising on mobile devices |
CN104850786A (en) * | 2015-06-03 | 2015-08-19 | 舒辉 | Environmental reconstruction based malicious-code integrity analysis method |
US20160330624A1 (en) * | 2011-11-04 | 2016-11-10 | Kt Corporation | Method for forming a trust relationship, and embedded uicc therefor |
US20170041794A1 (en) * | 2015-08-07 | 2017-02-09 | Qualcomm Incorporated | Validating authorization for use of a set of features of a device |
WO2017120097A1 (en) * | 2016-01-08 | 2017-07-13 | Capital One Services, Llc | Methods and systems for securing data in the public cloud |
CN107026825A (en) * | 2016-02-02 | 2017-08-08 | 中国移动通信集团陕西有限公司 | A kind of method and system for accessing big data system |
US9727749B2 (en) * | 2015-06-08 | 2017-08-08 | Microsoft Technology Licensing, Llc | Limited-access functionality accessible at login screen |
CN107733842A (en) * | 2016-11-08 | 2018-02-23 | 北京奥斯达兴业科技有限公司 | Method for authenticating and device based on cloud platform |
WO2018080727A1 (en) * | 2016-10-26 | 2018-05-03 | Intuit Inc. | Authorization to access a server in the cloud without obtaining an initial secret |
US10360403B2 (en) | 2017-04-12 | 2019-07-23 | International Business Machines Corporation | Cognitive API policy manager |
US10366240B1 (en) | 2017-01-25 | 2019-07-30 | Intuit Inc. | Authorization to access a server in the cloud without obtaining an initial secret |
US10412097B1 (en) | 2017-01-24 | 2019-09-10 | Intuit Inc. | Method and system for providing distributed authentication |
US10581861B2 (en) | 2017-09-12 | 2020-03-03 | International Business Machines Corporation | Endpoint access manager |
US10601807B2 (en) * | 2011-08-09 | 2020-03-24 | CloudPassage, Inc. | Systems and methods for providing container security |
Families Citing this family (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10075471B2 (en) | 2012-06-07 | 2018-09-11 | Amazon Technologies, Inc. | Data loss prevention techniques |
US9705674B2 (en) | 2013-02-12 | 2017-07-11 | Amazon Technologies, Inc. | Federated key management |
US10467422B1 (en) | 2013-02-12 | 2019-11-05 | Amazon Technologies, Inc. | Automatic key rotation |
US9081978B1 (en) * | 2013-05-30 | 2015-07-14 | Amazon Technologies, Inc. | Storing tokenized information in untrusted environments |
US9832171B1 (en) * | 2013-06-13 | 2017-11-28 | Amazon Technologies, Inc. | Negotiating a session with a cryptographic domain |
US10275766B2 (en) | 2013-09-24 | 2019-04-30 | Google Llc | Encrypting financial account numbers such that every decryption attempt results in valid account numbers |
US9313195B2 (en) | 2013-09-30 | 2016-04-12 | Protegrity Corporation | Collision avoidance in a distributed tokenization environment |
US9111116B2 (en) | 2013-09-30 | 2015-08-18 | Protegrity Corporation | Collision avoidance in a distributed tokenization environment |
EP2854069B1 (en) * | 2013-09-30 | 2019-06-05 | Protegrity Corporation | Collision avoidance in a distributed tokenization environment |
US10515370B2 (en) | 2013-10-09 | 2019-12-24 | The Toronto-Dominion Bank | Systems and methods for providing tokenized transaction accounts |
US11574300B1 (en) | 2014-04-30 | 2023-02-07 | Wells Fargo Bank, N.A. | Mobile wallet systems and methods using trace identifier using card networks |
US9397835B1 (en) | 2014-05-21 | 2016-07-19 | Amazon Technologies, Inc. | Web of trust management in a distributed system |
US9258121B2 (en) * | 2014-06-20 | 2016-02-09 | Gemalto Sa | Method to manage modification of encryption credentials |
US9438421B1 (en) | 2014-06-27 | 2016-09-06 | Amazon Technologies, Inc. | Supporting a fixed transaction rate with a variably-backed logical cryptographic key |
US9866392B1 (en) | 2014-09-15 | 2018-01-09 | Amazon Technologies, Inc. | Distributed system web of trust provisioning |
CA2906911C (en) * | 2014-09-29 | 2023-08-15 | The Toronto-Dominion Bank | Systems and methods for generating and administering mobile applications using pre-loaded tokens |
CN105825371A (en) * | 2015-01-07 | 2016-08-03 | 阿里巴巴集团控股有限公司 | Method and device for processing service |
US10469477B2 (en) | 2015-03-31 | 2019-11-05 | Amazon Technologies, Inc. | Key export techniques |
US10410210B1 (en) * | 2015-04-01 | 2019-09-10 | National Technology & Engineering Solutions Of Sandia, Llc | Secure generation and inversion of tokens |
CN106991298B (en) * | 2016-01-21 | 2021-02-02 | 斑马智行网络(香港)有限公司 | Access method of application program to interface, authorization request method and device |
US10903854B2 (en) | 2016-04-20 | 2021-01-26 | Micro Focus Llc | Replacing a subset of digits in a sequence |
US10389688B2 (en) * | 2016-08-23 | 2019-08-20 | NXT-Security, LLC | Vaultless tokenization engine |
US10607017B2 (en) * | 2017-01-04 | 2020-03-31 | Ca, Inc. | Restricting access to sensitive data using tokenization |
US10671753B2 (en) | 2017-03-23 | 2020-06-02 | Microsoft Technology Licensing, Llc | Sensitive data loss protection for structured user content viewed in user applications |
US10410014B2 (en) | 2017-03-23 | 2019-09-10 | Microsoft Technology Licensing, Llc | Configurable annotations for privacy-sensitive user content |
US10380355B2 (en) | 2017-03-23 | 2019-08-13 | Microsoft Technology Licensing, Llc | Obfuscation of user content in structured user data files |
US10860724B2 (en) * | 2017-06-13 | 2020-12-08 | Microsoft Technology Licensing, Llc | Active key rolling for sensitive data protection |
CN109040092B (en) * | 2018-08-17 | 2019-06-28 | 北京海泰方圆科技股份有限公司 | Data random encrypting method and device |
US11636473B2 (en) | 2018-11-08 | 2023-04-25 | International Business Machines Corporation | Altering account numbers into invalid account numbers for secure transmission and storage |
US20200279050A1 (en) * | 2019-02-28 | 2020-09-03 | SpyCloud, Inc. | Generating and monitoring fictitious data entries to detect breaches |
US11615214B2 (en) * | 2019-07-15 | 2023-03-28 | Micron Technology, Inc. | Cryptographic key management |
US11381393B2 (en) | 2019-09-24 | 2022-07-05 | Akamai Technologies Inc. | Key rotation for sensitive data tokenization |
US11748510B1 (en) * | 2019-10-29 | 2023-09-05 | United Services Automobile Association (Usaa) | Protection of personal data stored in vehicular computing systems |
US11201741B2 (en) * | 2020-03-03 | 2021-12-14 | The Prudential Insurance Company Of America | System for improving data security |
CN111934883B (en) * | 2020-07-16 | 2024-01-26 | 中国民航信息网络股份有限公司 | Credit card number tokenization method and system |
US20220067184A1 (en) * | 2020-08-28 | 2022-03-03 | Open Text Holdings, Inc. | Tokenization systems and methods for redaction |
US20220191018A1 (en) * | 2020-12-14 | 2022-06-16 | International Business Machines Corporation | Key rotation on a publish-subscribe system |
US11921891B2 (en) * | 2020-12-23 | 2024-03-05 | PB Analytics Inc. | Method for restricting access to a data owner's data |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090048997A1 (en) * | 2007-08-16 | 2009-02-19 | Verizon Data Services India Private Limited | Method and apparatus for rule-based masking of data |
WO2010005008A1 (en) * | 2008-07-11 | 2010-01-14 | 曙ブレーキ工業株式会社 | Pad clip for disk brake device |
US7783666B1 (en) * | 2007-09-26 | 2010-08-24 | Netapp, Inc. | Controlling access to storage resources by using access pattern based quotas |
US8458487B1 (en) * | 2010-03-03 | 2013-06-04 | Liaison Technologies, Inc. | System and methods for format preserving tokenization of sensitive information |
Family Cites Families (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6662237B1 (en) | 1999-06-24 | 2003-12-09 | Contivo, Inc. | System for documenting application interfaces and their mapping relationship |
SE9904094D0 (en) * | 1999-11-12 | 1999-11-12 | Protegrity Research & Dev | Method for reencryption of a database |
EP1352307A2 (en) | 2000-09-22 | 2003-10-15 | EDC Systems, Inc. | Systems and methods for preventing unauthorized use of digital content |
US7237123B2 (en) | 2000-09-22 | 2007-06-26 | Ecd Systems, Inc. | Systems and methods for preventing unauthorized use of digital content |
US20070079119A1 (en) * | 2000-11-16 | 2007-04-05 | Ulf Mattsson | Encryption key rotation |
US20060034456A1 (en) * | 2002-02-01 | 2006-02-16 | Secure Choice Llc | Method and system for performing perfectly secure key exchange and authenticated messaging |
JPWO2006003743A1 (en) | 2004-07-02 | 2008-04-17 | 和泰 隠岐 | Information hiding postcard and manufacturing method thereof |
US7710988B1 (en) * | 2005-03-11 | 2010-05-04 | Xambala Corporation | Method and system for non-deterministic finite automaton filtering |
EP1955221A4 (en) | 2005-12-01 | 2009-03-11 | Firestar Software Inc | System and method for exchanging information among exchange applications |
US7891563B2 (en) | 2007-05-17 | 2011-02-22 | Shift4 Corporation | Secure payment card transactions |
US8401183B2 (en) | 2007-12-27 | 2013-03-19 | Verizon Patent And Licensing Inc. | Method and system for keying and securely storing data |
US8578176B2 (en) | 2008-03-26 | 2013-11-05 | Protegrity Corporation | Method and apparatus for tokenization of sensitive sets of characters |
US8208627B2 (en) | 2008-05-02 | 2012-06-26 | Voltage Security, Inc. | Format-preserving cryptographic systems |
US8651374B2 (en) | 2008-06-02 | 2014-02-18 | Sears Brands, L.L.C. | System and method for payment card industry enterprise account number elimination |
US8751788B2 (en) | 2008-06-10 | 2014-06-10 | Paymetric, Inc. | Payment encryption accelerator |
US8584251B2 (en) | 2009-04-07 | 2013-11-12 | Princeton Payment Solutions | Token-based payment processing system |
US10748146B2 (en) | 2009-06-16 | 2020-08-18 | Heartland Payment Systems, Llc | Tamper-resistant secure methods, systems and apparatuses for credit and debit transactions |
US8595812B2 (en) | 2009-12-18 | 2013-11-26 | Sabre Inc. | Tokenized data security |
US8650129B2 (en) * | 2010-01-20 | 2014-02-11 | American Express Travel Related Services Company, Inc. | Dynamically reacting policies and protections for securing mobile financial transaction data in transit |
US8745094B2 (en) | 2010-03-01 | 2014-06-03 | Protegrity Corporation | Distributed tokenization using several substitution steps |
US9558494B2 (en) | 2010-04-19 | 2017-01-31 | Tokenex, L.L.C. | Devices, systems, and methods for tokenizing sensitive information |
US8850071B2 (en) | 2010-05-10 | 2014-09-30 | Liaison Technologies, Inc. | Map intuition system and method |
US8489894B2 (en) * | 2010-05-26 | 2013-07-16 | Paymetric, Inc. | Reference token service |
US8943574B2 (en) * | 2011-05-27 | 2015-01-27 | Vantiv, Llc | Tokenizing sensitive data |
US10318932B2 (en) | 2011-06-07 | 2019-06-11 | Entit Software Llc | Payment card processing system with structure preserving encryption |
-
2012
- 2012-06-20 US US13/527,867 patent/US20120324225A1/en not_active Abandoned
- 2012-06-20 US US13/527,860 patent/US20120321078A1/en not_active Abandoned
- 2012-06-20 US US13/527,837 patent/US8806204B2/en active Active
- 2012-06-20 US US13/527,852 patent/US8812844B2/en not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090048997A1 (en) * | 2007-08-16 | 2009-02-19 | Verizon Data Services India Private Limited | Method and apparatus for rule-based masking of data |
US7783666B1 (en) * | 2007-09-26 | 2010-08-24 | Netapp, Inc. | Controlling access to storage resources by using access pattern based quotas |
WO2010005008A1 (en) * | 2008-07-11 | 2010-01-14 | 曙ブレーキ工業株式会社 | Pad clip for disk brake device |
US8458487B1 (en) * | 2010-03-03 | 2013-06-04 | Liaison Technologies, Inc. | System and methods for format preserving tokenization of sensitive information |
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10601807B2 (en) * | 2011-08-09 | 2020-03-24 | CloudPassage, Inc. | Systems and methods for providing container security |
US8689355B1 (en) * | 2011-08-30 | 2014-04-01 | Emc Corporation | Secure recovery of credentials |
US10462668B2 (en) * | 2011-11-04 | 2019-10-29 | Kt Corporation | Method for forming a trust relationship, and embedded UICC therefor |
US20160330624A1 (en) * | 2011-11-04 | 2016-11-10 | Kt Corporation | Method for forming a trust relationship, and embedded uicc therefor |
US10091653B2 (en) * | 2011-11-04 | 2018-10-02 | Kt Corporation | Method for forming a trust relationship, and embedded UICC therefor |
US8972543B1 (en) * | 2012-04-11 | 2015-03-03 | Spirent Communications, Inc. | Managing clients utilizing reverse transactions |
US20140281480A1 (en) * | 2013-03-15 | 2014-09-18 | Vmware, Inc. | Systems and methods for providing secure communication |
US9602537B2 (en) * | 2013-03-15 | 2017-03-21 | Vmware, Inc. | Systems and methods for providing secure communication |
US20150095160A1 (en) * | 2013-10-01 | 2015-04-02 | Paschar Llc | Method and system for providing advertising on mobile devices |
CN104850786A (en) * | 2015-06-03 | 2015-08-19 | 舒辉 | Environmental reconstruction based malicious-code integrity analysis method |
US9727749B2 (en) * | 2015-06-08 | 2017-08-08 | Microsoft Technology Licensing, Llc | Limited-access functionality accessible at login screen |
US9959422B2 (en) | 2015-06-08 | 2018-05-01 | Microsoft Technology Licensing, Llc | Limited-access functionality accessible at lock screen |
US11082849B2 (en) * | 2015-08-07 | 2021-08-03 | Qualcomm Incorporated | Validating authorization for use of a set of features of a device |
KR20180039061A (en) * | 2015-08-07 | 2018-04-17 | 퀄컴 인코포레이티드 | Verify authorization for use of a set of features of the device |
TWI713544B (en) * | 2015-08-07 | 2020-12-21 | 美商高通公司 | Validating authorization for use of a set of features of a device |
KR102439686B1 (en) * | 2015-08-07 | 2022-09-01 | 퀄컴 인코포레이티드 | Validate authorization for use of a set of features of a device |
US20170041794A1 (en) * | 2015-08-07 | 2017-02-09 | Qualcomm Incorporated | Validating authorization for use of a set of features of a device |
WO2017120097A1 (en) * | 2016-01-08 | 2017-07-13 | Capital One Services, Llc | Methods and systems for securing data in the public cloud |
US11005823B2 (en) | 2016-01-08 | 2021-05-11 | Capital One Services, Llc | Field level security system for securing sensitive data |
US11843584B2 (en) | 2016-01-08 | 2023-12-12 | Capital One Services, Llc | Methods and systems for securing data in the public cloud |
US10419401B2 (en) | 2016-01-08 | 2019-09-17 | Capital One Services, Llc | Methods and systems for securing data in the public cloud |
US11171930B2 (en) | 2016-01-08 | 2021-11-09 | Capital One Services, Llc | Methods and systems for securing data in the public cloud |
US10819686B2 (en) | 2016-01-08 | 2020-10-27 | Capital One Services, Llc | Methods and systems for securing data in the public cloud |
CN107026825A (en) * | 2016-02-02 | 2017-08-08 | 中国移动通信集团陕西有限公司 | A kind of method and system for accessing big data system |
US10027669B2 (en) | 2016-10-26 | 2018-07-17 | Intuit Inc. | Authorization to access a server in the cloud without obtaining an initial secret |
WO2018080727A1 (en) * | 2016-10-26 | 2018-05-03 | Intuit Inc. | Authorization to access a server in the cloud without obtaining an initial secret |
CN107733842A (en) * | 2016-11-08 | 2018-02-23 | 北京奥斯达兴业科技有限公司 | Method for authenticating and device based on cloud platform |
US10412097B1 (en) | 2017-01-24 | 2019-09-10 | Intuit Inc. | Method and system for providing distributed authentication |
US10366240B1 (en) | 2017-01-25 | 2019-07-30 | Intuit Inc. | Authorization to access a server in the cloud without obtaining an initial secret |
US10902151B2 (en) | 2017-04-12 | 2021-01-26 | International Business Machines Corporation | Cognitive API policy manager |
US10360403B2 (en) | 2017-04-12 | 2019-07-23 | International Business Machines Corporation | Cognitive API policy manager |
US10581861B2 (en) | 2017-09-12 | 2020-03-03 | International Business Machines Corporation | Endpoint access manager |
Also Published As
Publication number | Publication date |
---|---|
US8812844B2 (en) | 2014-08-19 |
US20120321078A1 (en) | 2012-12-20 |
US8806204B2 (en) | 2014-08-12 |
US20120324223A1 (en) | 2012-12-20 |
US20120324555A1 (en) | 2012-12-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20120324225A1 (en) | Certificate-based mutual authentication for data security | |
US11314891B2 (en) | Method and system for managing access to personal data by means of a smart contract | |
US20210351931A1 (en) | System and method for securely processing an electronic identity | |
EP3298532B1 (en) | Encryption and decryption system and method | |
US11290446B2 (en) | Access to data stored in a cloud | |
JP4443224B2 (en) | Data management system and method | |
US7395436B1 (en) | Methods, software programs, and systems for electronic information security | |
US8458487B1 (en) | System and methods for format preserving tokenization of sensitive information | |
US20190238319A1 (en) | Rights management of content | |
US20080022136A1 (en) | Encryption load balancing and distributed policy enforcement | |
US20060190986A1 (en) | System and method for dynamically allocating resources | |
US20030229782A1 (en) | Method for computer identification verification | |
US20020147917A1 (en) | Distribution of secured information | |
US20210142319A1 (en) | Systems and methods for distributed data mapping | |
US11163893B2 (en) | Methods and systems for a redundantly secure data store using independent networks | |
US11425143B2 (en) | Sleeper keys | |
US11102005B2 (en) | Intelligent decryption based on user and data profiling | |
US10970408B2 (en) | Method for securing a digital document | |
US20240045988A1 (en) | Enhanced user security through a middle tier access application | |
GB2609651A (en) | Method and apparatus for protecting personal data | |
CN117540408A (en) | Attribute-based wildcard searchable encryption method and system | |
Browning | Security Features in the Teradata Database | |
NZ618683B2 (en) | Access control to data stored in a cloud |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:LIAISON TECHNOLOGIES, INC.;REEL/FRAME:041808/0027 Effective date: 20170329 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:LIAISON TECHNOLOGIES, INC.;REEL/FRAME:047950/0892 Effective date: 20130628 Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:LIAISON TECHNOLOGIES, INC.;REEL/FRAME:047950/0910 Effective date: 20170329 Owner name: LIAISON TECHNOLOGIES, INC., GEORGIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:048043/0532 Effective date: 20181217 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE LISTED PATENTS,NAMELY 5 NOS. LISTED AS PATENT NOS.(9590916,9344182,9650219,9588270,9294701),SHOULD BE LISTED AS APPLICATION NOS. PREVIOUSLY RECORDED ON REEL 047950 FRAME 0910. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY INTEREST;ASSIGNOR:LIAISON TECHNOLOGIES, INC.;REEL/FRAME:051255/0831 Effective date: 20170329 |