US20100325693A1 - Remote authorization for operations - Google Patents
Remote authorization for operations Download PDFInfo
- Publication number
- US20100325693A1 US20100325693A1 US12/871,163 US87116310A US2010325693A1 US 20100325693 A1 US20100325693 A1 US 20100325693A1 US 87116310 A US87116310 A US 87116310A US 2010325693 A1 US2010325693 A1 US 2010325693A1
- Authority
- US
- United States
- Prior art keywords
- secret
- service
- machine
- secure
- acquisition service
- 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.)
- Granted
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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- 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
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/081—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying self-generating credentials, e.g. instead of receiving credentials from an authority or from another peer, the credentials are generated at the entity itself
Definitions
- the invention relates generally to security and more particularly to techniques for remote authorization for operations.
- FIPS FIPS
- Some automated process may not be started without security credentials. This entails having a role-based or identity-based individual being physically present and authenticated at the site of the system, having the automated process, to supply the credential information before the automated process may be started. It is clear that such a requirement has caused a lot of operational and logistical issues within the U.S. federal government and within enterprises (vendors) that do business with the U.S. government or supply security systems on behalf of the U.S. government.
- Crypto Officers To comply with FIPS, a small set of individual security positions have been created with proper clearance to supply security credentials. These individuals are referred to as Crypto Officers. Crypto Officers must be hands on for certain configuration and startup events of security systems. Unfortunately, this puts a severe strain and a lot of unnecessary demand on the limited Crypto Officers. In fact, the U.S. government is so concerned about the availability and presence of the Crypto Officers that no two officers having overlapping duties may be physically present in the same building. So, and quite literally, when one officer enters a building, another officer present exits the building.
- a common practice among government vendors is to have two modes of operation for their systems: a FIPS mode and a non-FIPS mode. If a FIPS mode of operation is used, then a Crypto Officer must be physically present at the site or device of the system for startup of a particular operation or service. In a non-FIPS mode of operation, the operation or service may be started without the presence of the Crypto Officer that supplies the credentials.
- the FIPS mode of operation permits a vendor to receive the necessary certifications and grades from a reviewing federal agency to get their services and products in the door.
- the FIPS mode may never actually be started or configured with the product or service of the vendor for the federal government because of the perceived operational issues that may quite literally require a Crypto Officer to be employed and be physically present on site of the vendor or the deployed location of the product or service 24 hours a day and 7 days a week (24 ⁇ 7).
- a Crypto Officer has to be certified and cleared for each system that is to be under the control of the Crypto Officer.
- a Crypto Officer has to be certified and cleared for each system that is to be under the control of the Crypto Officer.
- a specifically certified Crypto Officer for the system that is down has to be available when that system is down.
- techniques for acquiring remote authorization to initiate secure operations are provided. More specifically, and in an embodiment, a method for acquiring an access key to remotely authorize the initiation of a secure operation.
- a request is received for authorization to initiate an operation of a security system.
- a remote authorization principal is notified of the request and a secret is acquired in response to that notification.
- an access key is acquired in response to the secret and the access key is submitted to the security system for purposes of initiating the operation.
- FIG. 1 is a diagram of a method for acquiring an access key to remotely authorize the initiation of a secure operation, according to an example embodiment.
- FIG. 2 is a diagram of method for remotely supplying a secret used to acquire the access key described with the processing of the FIG. 1 , according to an example embodiment.
- FIG. 3 is a diagram of a method for initiating a secure operation in response to the access key described with the processing of the FIG. 1 and obtained from the secret supplied with the processing of the FIG. 2 , according to an example embodiment.
- FIG. 4 is a diagram of a remote authorization system, according to an example embodiment.
- FIG. 5 is a diagram for example interactions that may occur for various components and techniques discussed with the example embodiments.
- a “resource” includes a user, content, a processing device, a node, a service, a system, a directory, a data store, groups of users, combinations of these things, etc.
- a “principal” is a specific type of resource that has one or more unique identities.
- An “authorized principal” is a specific type of resource that has had one of its identities authenticated for interacting with a given resource or a given set of resources. According to an embodiment, an authorized principal is a FIPS compliant Crypto Officer that is certified for a given resource, where that given resource is a security system desiring an initiation of a secure operation.
- An authorized principal is remote if for a given transaction that authorized principal is not physically and geographically present at the resource or set of resource with which the authorized principal is authenticated. Stated another way, the authorized principal is remote if a Wide Area Network (WAN), such as the Internet, a telephone network, or other network is used for the authorized principal to directly or indirectly communicate with the resource or set of resources.
- WAN Wide Area Network
- the use of the term “remote” is relative, such that the authorized principal is remote to the resource or resources from the perspective of the resources; yet, from the perspective of the authorized principal the resource or resources are remote from authorized principal.
- Direct or indirect communication between the authorized principal and its resource (security system) is secure.
- the network may be secure, such as a dedicated transmission line, and/or the network may be insecure but use secure communications, such as encryption, Virtual Private Networks, and the like.
- secure and insecure networks utilizing secure communications during any particular direct or indirect communication between the authorized principal and the security system.
- Various embodiments of this invention can be implemented in existing network architectures, security systems, and/or communication devices.
- the techniques presented herein are implemented in whole or in part in the Novell® network, proxy server products, email products, operating system products, and/or directory services products distributed by Novell®, Inc., of Provo, Utah.
- FIG. 1 is a diagram of a method 100 for acquiring an access key to remotely authorize the initiation of a secure operation, according to an example embodiment.
- the method 100 (hereinafter “authorization acquisition service”) is implemented in a machine-accessible and readable medium.
- the authorization acquisition service is operational over and processes within a network.
- the network may be wired, wireless, or a combination of wired and wireless.
- the authorization acquisition service reflects an intermediary service that permits a remote authorization principal to indirectly communicate with a security system for purposes of initiating a secure operation under control of the security system.
- the authorization acquisition service receives a request for authorization to initiate a secure operation.
- the secure operation may be related to startup of a secure system or device or may be related to a specific secure feature of a service that is already processing within the secure system or secure device.
- the request for authorization is received from a security system or service. It is noted that the terms service, system, and even operation may be used interchangeably herein. So, the secure operation may be viewed as a sub service or a larger secure system or service.
- the receive request may include a variety of additional information.
- the security system may communicate a policy to the authorization acquisition service indicating who should be consulted to assist in obtaining the access key needed for initiating the secure operation.
- the policy may also communicate the technique and devices that the authorization acquisition service should consult to acquire the access key. In some cases, some or all of this information may be preconfigured within the authorization acquisition service, such that it is not associated with the request and dynamically communicated with the request from the security system.
- the authorization acquisition service notifies a remote authorization principal (RAP) of the request by the security system. This prompts the RAP to deliver or cause to be delivered a secret.
- the secret is known or accessible only to the RAP and not the authorization acquisition service.
- the authorization acquisition service uses the secret obtained from the RAP as a key to open a secret store or lock box for purposes of acquiring the access key.
- the access key is used by the security system to authorize the initiation of the secure operation within the security system.
- the request may be reformatted and augmented or just forwarded to the RAP by the authorization acquisition service in a variety of formats or combinations of formats. So, the request may be sent to the RAP or a device of the RAP (such as for example a cell phone) as a text message, a voice message, an email to an email account of the RAP, an event to a World-Wide Web (WWW) service, etc.
- a device of the RAP such as for example a cell phone
- WWW World-Wide Web
- the request may be sent via multiple formats or channels and may be augmented with additional information.
- the authorization acquisition service may send a text message to an RAP on its phone indicating that the security system is down and there is an authorized request to initiate a startup procedure (secure operation) at the same time a voice message may be sent to the RAP informing the RAP of a random passkey to use with the RAP's credentials to gain access to a random key generator or service and acquire the desired secret that the authorization acquisition service desires to unlock a secret store and get the access key.
- the authorization acquisition service may also identify the mechanism by which the RAP may obtain the secret that is desired using credentials of the RAP. An example, of this was supplied above.
- the authorization acquisition service may work in cooperation with the RAP to acquire the secret that the authorization acquisition service desires, such that neither may obtain the secret only without at least some assistance from the other.
- the authorization acquisition service obtains the desired secret from the RAP in response to the notification that was sent to the RAP at 120 .
- the secret may be received in a variety of formats and either directly from the RAP or indirectly from the RAP in response to actions of the RAP with secure devices and/or services. Delivery may be simple or complex. Moreover, delivery itself may be driven by policy and communicated dynamically from the authorization acquisition service to the RAP.
- the secret may be received as a touch tone response from a cell phone or communication device of the RAP in response to the notification.
- the secret may be received from a secure WWW service that the RAP access with a pass key, which upon access causes the WWW service to deliver the secret to the authorization acquisition service.
- the RAP may never know what the secret was and may not care, but the RAP and the RAP's credentials were needed to cause the secret to be delivered to the authorization acquisition service.
- the authorization acquisition service may receive the secret as a text message, as an email message, or event as a voice message (the voice message may be analyzed for voice pattern recognition associated with the RAP).
- biometrics may also be used to authenticate responses having the secret as being from the RAP.
- the authorization acquisition service may receive the secret directly from a secure device activated by the RAP in response to the request. So, the RAP may use a smart card or memory device to obtain or generate the secret and interface a reader or network interface to a network where the secret is obtained and sent either directly to the authorization acquisition service or to another service and then to the authorization acquisition service.
- the authorization acquisition service may receive the secret as a random and/or optionally a time sensitive or dependent secret. So, the RAP may access a device or service to obtain the secret and then that secret is either communicated by the RAP or by another device or service to the authorization acquisition service. Examples of this were discussed above.
- the authorization acquisition service acquires the access key in response to a successfully received secret. That is, the secret serves itself as a key to unlock a secret store, service, or device, where the true access key is acquired.
- the lock box, secret store, service, or device that has the access key requires more than one secret from more than one RAP to open up and supply the desired access key.
- the authorization acquisition service may simultaneously perform the processing discussed with respect to 120 - 140 , at 141 , with one or more additional RAP's and may use the additional secret(s) to completely unlock and obtain the access key.
- the secret obtained, at 130 is the desired access key which is acquired, at 140 .
- the RAP may directly supply the access key in cases where the secret is in fact the access key.
- Policy may notify the authorization acquisition service that the RAP is directly supplying the desired access key, such that the authorization acquisition service recognizes the secret obtained as the access key.
- the authorization acquisition service submits the access key to the security system for purposes of initiating the secure operation.
- the access key may be regularly changing and using a mechanism to change that is known only to the secret store housing the access key and the security system.
- the secret store and the security system may then be time synchronized with one another, such that at any particular point in time both of them possess the same access key.
- the security system does not permit the secure operation to be initiated without the authorization acquisition service delivering a valid access key that authorizes the initiation of the secure operation within the security system.
- the authorization acquisition service may, pursuant to policy, be required to acquire multiple access keys to successfully authenticate the secure operation for initiation within the security system.
- the authorization acquisition service may concurrently or simultaneously perform the processing of 120 - 140 , at 151 to acquire multiple different access keys, each of which are needed by the security system to permit the secure operation to proceed. Note that this is different from the processing at 141 in that multiple secrets from multiple RAP's at 141 were used to obtain a single access key; however, at 151 , multiple secrets from multiple RAP's are used to obtain multiple access keys.
- policies may be predefined and configured within the authorization acquisition service or may be dynamically communicated and communicated in real time to the authorization acquisition service from the security system. Accordingly, in an embodiment, at 160 , the processing at 120 and 140 may be driven in response to static or dynamic policies.
- the processing technique of the authorization acquisition service permits FIPS 140-2 security to occur with remote or roaming Crypto Officers that do not have to physically and geographically present at the security system to initiate a secure operation when needed. Additionally, the processing technique provides for enhanced security for authorizing any secure operation remotely in a geographically independent manner.
- FIG. 2 is a diagram of method 200 for remotely supplying a secret used to acquire the access key described with the processing of the FIG. 1 , according to an example embodiment.
- the method 200 (hereinafter “remote authorization principal (RAP) device service” is implemented in a machine-accessible and readable medium and is operational over a network.
- the network may be wired, wireless, or a combination of wired and wireless.
- remote authorization principal device service interacts with the authorization acquisition service represented by the method 100 to supply a secret that the authorization acquisition service uses to acquire an access key that is supplied to the security system to initiate the secure operation.
- the RAP device service receives a request for a secret from a remote authorization acquisition service (RAAS), such as the RAAS represented by the method 100 of the FIG. 1 .
- the RAP device service processes on a device that interacts with an RAP.
- the RAP is a FIPS 140-2 compliant Crypto Officer and the device that the RAP device service processes on is a cell phone or a voice-enabled communication device that interacts with and is operated by the RAP.
- the RAP device service processes on a voice-enabled communication device, such as but not limited to a voice over the Internet Protocol (IP) (VoIP) phone, a cell phone, a satellite phone, etc.
- IP Internet Protocol
- the identity of the sources that have the secret may be unknown to the RAP device service before receipt of the request. That is, the request itself may identify the identity of the sources having the secret and may also identify the technique that the RAP device service is to use to acquire the secret from the one or more sources. Thus, a key may be provided to the RAP device service and that key unlocks a source and causes the source to produce the desired secret.
- the RAP device service may also receive the request initially in a variety of disparate formats or a combination of formats and/or channels. So, the request may be received from the RAAS directly as a text message, an email, a voice message, or various combinations of these things. Alternatively, the request may be received indirectly from the RAAS via a service that the RAAS activates causing that service to raise an event or event code to the RAP device service.
- the RAP device service acquires a secret from one or more sources in response to the request received from the RAAS. This may occur in a variety of manners and via a variety of mechanisms.
- the RAP device service may interface a device or service with the network to acquire the secret. That is, the RAP device service may activate or cause to be activated a device or service that supplies the secret over the network.
- the secret may be directly supplied back to the RAP device service or may be supplied to the RAAS independent of the RAP device service after the RAP device service caused the device or service to generate and/or produce the desired secret.
- the RAP device service may access a random secret generation device or service for purposes of acquiring the secret desired by the RAAS.
- the RAP device service may not know in advance the secret and may not ever know the secret if the random device or service directly delivers the produced or generated secret to the RAAS on behalf of the RAP device service.
- the RAP device service causes the secret to be communicated to the RAAS.
- the RAP device service may directly supply this secret to the RAAS.
- the RAP device service may initiate and cause other devices or services to deliver the secret directly to the RAAS on behalf of the RAP device service. Example scenarios for this were discussed above.
- acquiring the secret need not be complex and may be straightforward. So, for example, a source may be a Crypto Officer having information in his head that is acquired at 220 by that officer inputting it into a device that the RAP device service is processing on, such as a cell phone. The RAP device service may then directly supply the secret over the network to the RAAS at 230 . Of course much more complicated and varied situations and processing may occur as was described above. It is also worthy to note that each request for a secret for even the same secure operation may be varied, such that the exact processing flow is random. In such cases, the processing at 211 permits the RAP device service to dynamically adjust and account for varying processing flows used to acquire the desired secret.
- the processing of the RAAS uses the secret to acquire an access key from a secret store and delivers the access key to the security system.
- the security system then authenticates the access key and if verified initiates the secure operation within the security system.
- FIG. 3 is a diagram of a method 300 for initiating a secure operation in response to the access key described with the processing of the FIG. 1 and obtained from the secret supplied with the processing of the FIG. 2 , according to an example embodiment.
- the method 300 (hereinafter “security system service” is implemented in a machine-accessible and readable medium and is operational over a network.
- the network may be wired, wireless, or a combination of wired and wireless.
- the security system service represents processing of a security system that controls and determines whether a secure operation is initiated.
- the security system service interacts directly with the authorization acquisition service represented by the method 100 of the FIG. 1 and indirectly with the remote authorization principal device service represented by the method 200 of the FIG. 2 .
- the security system service may be implemented as a sub service or enhancement to an existing security system so that it is designed to interact with the authorization acquisition service (AAS), such as the AAS represented by the method 100 of the FIG. 1 .
- AAS authorization acquisition service
- the security system service detects a request to initiate a secure operation within a security system.
- This can occur in a variety of manners. For example, there may be an attempt to boot up a device or services associated with the security system.
- the secure operation does not have to be a startup operation; that is, it may be a request to execute an operation that requires extraordinary security precautions. In a military situation this may be an operation that raises a threat level or that initiates some kind of strike. In other cases, the secure operation may actually be a shutdown of a running service or process. So, the secure operation can be any operation that requires or is associated with extraordinary authorization procedures before that secure operation is initiated within the security system.
- the security system service evaluates policy associated with authorizing the initiation. So, the security system being monitored by the security system service may include a variety of secure operations each of which may have different levels or security procedures. A policy may be associated with a single secure operation or a group of select secure operations. The policy may drive the processing flow and content of information communicated and expected by the security system service before any given secure operation is properly authenticated and initiated after a request to do the same is detected.
- the security system service makes a request to an AAS for an access key or set of access keys pursuant to instructions defined in the policy evaluated at 320 .
- the policy may indicate that one or more access keys are needed to properly authenticate the request for initiating the secure operation and the security system service asks the AAS to attempt to acquire the access key or keys. If the AAS is unable to acquire the access key or keys then the secure operation will not be initiated.
- the policy may put time limits on the elapsed amount of time for the AAS to deliver the access key or keys and if there is no delivery during that elapsed period of time, then any access key or keys delivered after that time will be ignored or considered void.
- the security system service may also include a variety of dynamic and real time information in the request to the AAS for the access key or keys. So, the security system service may actually identify the access key or keys that it needs to authenticate the secure operation.
- the identifier may identify a type or name for a given access key or access keys.
- the AAS may then be configured to identify specific RAPS in response to these identifiers and follow its own procedures for eventually acquiring the access key or keys.
- the security system service may also identify a procedure for the AAS to follow in collecting the access key and that procedure may be randomly altered by the security system service.
- a procedure may indicate which lock box or secret store that the AAS is to use to acquire the access key or keys and/or may indicate which random secret or key generation service a RAP should access to acquire a time-sensitive secret that the AAS may then use to access the secret store.
- procedures and processing flows may be embodied in the request from the security system service to the AAS. Each of which are intended to fall within the scope of the disclosure presented.
- the request made from the security system service to the AAS results in the AAS interacting with one or more RAP's in the manner discussed above with respect to the method 100 of the FIG. 1 .
- the interactions of devices or services of the RAP were also described with respect to the method 200 of the FIG.
- the security system service may receive a requested access key or keys from the AAS in response to successfully processing of the AAS to acquire secrets from one or more RAP's.
- the access keys or keys are then authorized or verified by the security system service and, assuming success, the secure operation is initiated within the security system.
- the security system service may periodically synchronize with one or more secret stores to ensure the access key or keys are even more secure and non reproducible by intruders.
- the security system service and a secret store may each randomly generate access keys on a regular basis (e.g., every 10 minutes).
- the security system service and the secret store may use the same random key generator and they may be clock synchronized with one another and periodically synchronize clocks with one another. So, the keys are never transferred between the two but clock or time settings are in a regular fashion.
- the security system service and the secret store are recognizing the same access key.
- the security system service may not have to store the access key, that is a hash for the access key or even the access key itself may be generated upon request. This provides for even greater security.
- the security system service may supply the access key or keys to a secure loader for verification and for initiation of the secure operation. So, the verification of the access key and initiation of the secure operation may be further delegated to a secure service or module within the security system service.
- the methods 100 , 200 , and 300 may be implemented within machine-accessible or device-accessible media as instructions.
- the instructions when executed by a machine performing the processing of the methods 100 , 200 , and 300 depicted in the FIGS. 1-3 , respectively.
- the media may be removable; such that when it is interfaced to the machine the instructions are uploaded to the machine and processed.
- the media may be prefabricated with the instructions within the machine within the memory and/or storage. Still further, the media may be associated with a remote network machine and downloaded to another processing machine for execution.
- FIG. 4 is a diagram of a remote authorization system 400 , according to an example embodiment.
- the remote authorization system 400 is implemented in a machine-accessible and readable medium and is accessed and processed over a network.
- the network may be wired, wireless, or a combination of wired and wireless.
- the remote authorization system 400 implements, among other things, the authorization acquisition service represented by the method 100 of the FIG. 1 .
- the remote authorization system 400 interacts with the remote authorization principal device service represented by the method 200 of the FIG. 2 and with the security system service represented by the method 300 of the FIG. 3 .
- the remote authorization system 400 includes a secret store 401 and an authorization acquisition service 402 . Each of these will now be discussed in turn.
- the secret store 401 may be any secure hardware and/or software service that houses access keys or that is capable of producing access keys on demand.
- the access keys are consumed by a security system service, such as the security system service represented by the method 300 of the FIG. 3 for purposes of authorizing the initiation of a secure operation.
- the access keys are acquired by the authorization acquisition service (AAS) 402 after the AAS 402 produces one or more secrets to access the secret store 401 .
- the secrets may themselves be considered keys, thus the terminology of secrets and keys may be used interchangeably herein and above. For purposes of illustration the terminology secrets have been used to distinguish what the secret store 401 uses to unlock it versus what the security system uses to initiate the secure operation.
- the secret store 401 may periodically and randomly update or change the access keys or the technique it uses to generate an access key on demand. This random technique is also know to the security system and the security system and the secret store 401 time synchronize or clock synchronize with one another on a periodic bases to ensure that are any particular point in time that both the secret store 401 and the security system have the same access key or set of access keys.
- the secrets used by the AAS 402 to unlock the secret store 401 may also be periodically and randomly updated or changed by both the secret store 401 and security devices or services associated with or accessible to the RAP's.
- a RAP may have a random key or secret generator that is clock synchronized with the secret store 401 , such that at any particular point in time the secret generator will produce a random secret that the secret store 401 will recognize as being valid.
- the AAS 402 interacts with three entities the security system, the secret store 401 , and RAP's. In some cases, interactions with the RAP's may result in other devices or services communicating with the AAS 402 . For example, the actions or procedures of an RAP may result in a secure service, such as a secure WWW service, delivering a secret to the AAS 402 .
- a secure service such as a secure WWW service
- the AAS 402 receives authorization requests from the security system. Those requests may optionally include a variety of information, such as but not limited to, the identity of one or more RAP's, a procedure to use to acquire the desired access keys, the identity of one or more secret stores 401 , etc. It is also noted that some of this information may be preconfigured within the AAS 402 , so the specifics as to how and where to get the access keys may be statically resolved or dynamically resolved or various combinations of both static and dynamic.
- the procedures themselves may be random, such that no two situations for authorizing a same security operation within the security system uses a same access key, a same secret store 401 , a same RAP, and/or a same procedure that was used with a prior authorization of that security operation.
- the AAS 402 in response to authorization requests, sends notifications and other requests to one or more RAP's to acquire secrets that are used to open the secret store 401 and acquire the access key or access keys. Examples of how these notifications occur were described in detail above with respect to the AAS represented by the method 100 of the FIG. 1 .
- Successful unlocking of the secret store 401 produces the access key or keys, which the AAS 402 submits to the security system for purposes of initiating the secure operation within that security system.
- FIG. 5 is a diagram for example interactions that may occur for various components and techniques discussed with the example embodiments.
- the diagram depicts a variety of components that interact with one another and include labels A-G representing data communication and interaction between the components.
- FIG. 5 An example security system is shown in FIG. 5 as a FIPS 140-2 Compliant System. It interacts direct with an authorization acquisition service via communication link A. So, the FIPS System may receive a resource to execute a secure operation such as the startup process labeled in FIG. 5 . Before the startup process is initiated, the FIPS Compliant System sends a request for an access key to the authorization acquisition service over A.
- the authorization acquisition service then contacts authorizing entities or devices of the authorizing entities (referred to above as remote authorization principals and the remote authorization principal device service represented by the method 200 of the FIG. 2 ). Examples of the authorization acquisition service were also provided above with respect to the method 200 of the FIG. 2 and the system 400 of the FIG. 4 . It is also noted that the authorization acquisition service may be specialized, dedicated, and secure hardware with software designed to perform the features discussed herein or may be software operational on any secured hardware device, such as a proxy, firewall, gateway, etc.
- the authorization acquisition service may include a policy or may be delivered a policy with the request for the access key via A.
- the policy informs the authorization acquisition service what secrets are needed and how they are to be obtained. It may be that more than one authorizing entity and more than one secret is needed for the authorization acquisition service to obtain the access key or keys from the lock box, or secret store.
- link G depicts a situation where policy may dictate that two secrets from two separate authorizing entities are needed to unlock the lock box (secret store) and acquire the access key.
- the authorizing entity may be contacted via a cellular, satellite, or mobile phone via communication link B by the authorization acquisition service. As mentioned above a different authorizing entity may also be contacted over link G. Assuming the device of the authorizing entity is a cell phone, then the authorizing entity may receive a request for the secret from the authorization acquisition service as a text message, a voice message, or combinations of text and voice messages.
- the request for the secret may include multiple messages to identify the situation to the authorizing entity, identity the FIPS System involved, identity the startup procedure, and perhaps identify a location as to where the authorizing entity may acquire the needed secret.
- the authorization acquisition service may actually instruct the authorizing entity where to acquire the secret it desires. For example, it may act the authorizing entity to use a smart card or other key generation technique via D and use that key to access a WWW service via E. The WWW service may then upon presentation of the key acquired via D send the secret to the authorization acquisition service via C.
- the techniques used by the first authorizing entity contacted via B may be the same or different then the techniques used by any needed second authorizing entity to supply its secret via G.
- a variety of permutations and processing scenarios may be used by the authorizing entity to directly or indirectly deliver the secret to the authorization acquisition service.
- the authorizing entity may use touch tone codes to deliver the secret directly to the authorization acquisition service via B. It can be more complicated such that a random key is supplied to the authorizing entity either via B or via D and that random key gets the authorizing entity access to another service where the secret is obtained and either delivered directly to the authorizing entity for delivery via B or delivered on behalf of the authorizing entity via C.
- the authorization acquisition service uses the secrets to access a secret store of lock box via F to acquire one or more access keys. These access keys are then supplied to the FIPS System via A. The FIPS System then uses the access key or keys to initiate the startup operation or supplies the access key or keys to a secure loader to initiate the startup process.
- the access keys themselves may be independently and randomly changing within the lock box and within the FIPS System. These changes may be temporal-based and/or entirely random.
- the lock box and the FIPS System are synchronized because they use the same mechanism and are time synchronized with one another such that when an access key changes it is changed on both the lock box and the FIPS System.
- a secure and remote authorization technique may be implemented to authorize an operation of a security system.
- This technique complies with FIPS 140-2 and, among other things, may be used to eliminate the physical presence requirements of FIPS Crypto Officers without sacrificing security procedures.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Telephonic Communication Services (AREA)
- Storage Device Security (AREA)
- Mobile Radio Communication Systems (AREA)
- Lock And Its Accessories (AREA)
Abstract
Description
- This application is a divisional of U.S. patent application Ser. No. 11/392,195, filed on Mar. 29, 2006, which is incorporated herein by reference in its entirety.
- The invention relates generally to security and more particularly to techniques for remote authorization for operations.
- Electronic security is a very high priority within governments and enterprises. In fact, the United States (U.S.) federal government has promulgated stringent standards that seek to address electronic security for U.S. systems, devices, services, administrative agencies, organizations, etc. The Federal Information Processing Standard (FIPS) 140-2 addresses cryptographic standards for U.S. federal organizations. Security has always been a challenge but after the advent of Sep. 11, 2001, the U.S. government has placed even greater emphasis and resources on security issues.
- One aspect of FIPS is that some automated process may not be started without security credentials. This entails having a role-based or identity-based individual being physically present and authenticated at the site of the system, having the automated process, to supply the credential information before the automated process may be started. It is clear that such a requirement has caused a lot of operational and logistical issues within the U.S. federal government and within enterprises (vendors) that do business with the U.S. government or supply security systems on behalf of the U.S. government.
- To comply with FIPS, a small set of individual security positions have been created with proper clearance to supply security credentials. These individuals are referred to as Crypto Officers. Crypto Officers must be hands on for certain configuration and startup events of security systems. Unfortunately, this puts a severe strain and a lot of unnecessary demand on the limited Crypto Officers. In fact, the U.S. government is so concerned about the availability and presence of the Crypto Officers that no two officers having overlapping duties may be physically present in the same building. So, and quite literally, when one officer enters a building, another officer present exits the building.
- Because of this stringent policy, a common practice among government vendors is to have two modes of operation for their systems: a FIPS mode and a non-FIPS mode. If a FIPS mode of operation is used, then a Crypto Officer must be physically present at the site or device of the system for startup of a particular operation or service. In a non-FIPS mode of operation, the operation or service may be started without the presence of the Crypto Officer that supplies the credentials.
- So in practice, the FIPS mode of operation permits a vendor to receive the necessary certifications and grades from a reviewing federal agency to get their services and products in the door. However, the FIPS mode may never actually be started or configured with the product or service of the vendor for the federal government because of the perceived operational issues that may quite literally require a Crypto Officer to be employed and be physically present on site of the vendor or the deployed location of the product or service 24 hours a day and 7 days a week (24×7).
- To complicate matters further, a Crypto Officer has to be certified and cleared for each system that is to be under the control of the Crypto Officer. Thus, not just any Crypto Officer has to be available when a system is down; rather, a specifically certified Crypto Officer for the system that is down has to be available when that system is down.
- Thus, what is needed is a mechanism, which allows a certified and qualified Crypto Officer(s) to remotely provide security credentials, where those security credentials are necessary for permitting secured systems to acquire remote authorizations in order for the secured systems to be operated in accordance with security policy.
- In various embodiments, techniques for acquiring remote authorization to initiate secure operations are provided. More specifically, and in an embodiment, a method for acquiring an access key to remotely authorize the initiation of a secure operation. A request is received for authorization to initiate an operation of a security system. A remote authorization principal is notified of the request and a secret is acquired in response to that notification. Next, an access key is acquired in response to the secret and the access key is submitted to the security system for purposes of initiating the operation.
-
FIG. 1 is a diagram of a method for acquiring an access key to remotely authorize the initiation of a secure operation, according to an example embodiment. -
FIG. 2 is a diagram of method for remotely supplying a secret used to acquire the access key described with the processing of theFIG. 1 , according to an example embodiment. -
FIG. 3 is a diagram of a method for initiating a secure operation in response to the access key described with the processing of theFIG. 1 and obtained from the secret supplied with the processing of theFIG. 2 , according to an example embodiment. -
FIG. 4 is a diagram of a remote authorization system, according to an example embodiment. -
FIG. 5 is a diagram for example interactions that may occur for various components and techniques discussed with the example embodiments. - A “resource” includes a user, content, a processing device, a node, a service, a system, a directory, a data store, groups of users, combinations of these things, etc. A “principal” is a specific type of resource that has one or more unique identities. An “authorized principal” is a specific type of resource that has had one of its identities authenticated for interacting with a given resource or a given set of resources. According to an embodiment, an authorized principal is a FIPS compliant Crypto Officer that is certified for a given resource, where that given resource is a security system desiring an initiation of a secure operation.
- An authorized principal is remote if for a given transaction that authorized principal is not physically and geographically present at the resource or set of resource with which the authorized principal is authenticated. Stated another way, the authorized principal is remote if a Wide Area Network (WAN), such as the Internet, a telephone network, or other network is used for the authorized principal to directly or indirectly communicate with the resource or set of resources. The use of the term “remote” is relative, such that the authorized principal is remote to the resource or resources from the perspective of the resources; yet, from the perspective of the authorized principal the resource or resources are remote from authorized principal.
- Direct or indirect communication between the authorized principal and its resource (security system) is secure. So, the network may be secure, such as a dedicated transmission line, and/or the network may be insecure but use secure communications, such as encryption, Virtual Private Networks, and the like. There may also be a variety of combinations of secure and insecure networks utilizing secure communications during any particular direct or indirect communication between the authorized principal and the security system.
- Various embodiments of this invention can be implemented in existing network architectures, security systems, and/or communication devices. For example, in some embodiments, the techniques presented herein are implemented in whole or in part in the Novell® network, proxy server products, email products, operating system products, and/or directory services products distributed by Novell®, Inc., of Provo, Utah.
- Of course, the embodiments of the invention can be implemented in a variety of architectural platforms, operating and server systems, devices, systems, or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.
-
FIG. 1 is a diagram of amethod 100 for acquiring an access key to remotely authorize the initiation of a secure operation, according to an example embodiment. The method 100 (hereinafter “authorization acquisition service”) is implemented in a machine-accessible and readable medium. The authorization acquisition service is operational over and processes within a network. The network may be wired, wireless, or a combination of wired and wireless. The authorization acquisition service reflects an intermediary service that permits a remote authorization principal to indirectly communicate with a security system for purposes of initiating a secure operation under control of the security system. - At 110, the authorization acquisition service receives a request for authorization to initiate a secure operation. The secure operation may be related to startup of a secure system or device or may be related to a specific secure feature of a service that is already processing within the secure system or secure device. The request for authorization is received from a security system or service. It is noted that the terms service, system, and even operation may be used interchangeably herein. So, the secure operation may be viewed as a sub service or a larger secure system or service.
- The receive request may include a variety of additional information. For example, the security system may communicate a policy to the authorization acquisition service indicating who should be consulted to assist in obtaining the access key needed for initiating the secure operation. The policy may also communicate the technique and devices that the authorization acquisition service should consult to acquire the access key. In some cases, some or all of this information may be preconfigured within the authorization acquisition service, such that it is not associated with the request and dynamically communicated with the request from the security system.
- At 120, the authorization acquisition service notifies a remote authorization principal (RAP) of the request by the security system. This prompts the RAP to deliver or cause to be delivered a secret. The secret is known or accessible only to the RAP and not the authorization acquisition service. The authorization acquisition service uses the secret obtained from the RAP as a key to open a secret store or lock box for purposes of acquiring the access key. The access key is used by the security system to authorize the initiation of the secure operation within the security system. The various details and interactions of this processing will now be discussed in greater detail.
- According to an embodiment, at 121, the request may be reformatted and augmented or just forwarded to the RAP by the authorization acquisition service in a variety of formats or combinations of formats. So, the request may be sent to the RAP or a device of the RAP (such as for example a cell phone) as a text message, a voice message, an email to an email account of the RAP, an event to a World-Wide Web (WWW) service, etc.
- As was mentioned above, the request may be sent via multiple formats or channels and may be augmented with additional information. So, the authorization acquisition service may send a text message to an RAP on its phone indicating that the security system is down and there is an authorized request to initiate a startup procedure (secure operation) at the same time a voice message may be sent to the RAP informing the RAP of a random passkey to use with the RAP's credentials to gain access to a random key generator or service and acquire the desired secret that the authorization acquisition service desires to unlock a secret store and get the access key. It should be kept in mind that this is but one example and that a variety of permutations may exist and used with the teachings presented herein.
- According to another embodiment, at 122, the authorization acquisition service may also identify the mechanism by which the RAP may obtain the secret that is desired using credentials of the RAP. An example, of this was supplied above. The authorization acquisition service may work in cooperation with the RAP to acquire the secret that the authorization acquisition service desires, such that neither may obtain the secret only without at least some assistance from the other.
- At 130, the authorization acquisition service obtains the desired secret from the RAP in response to the notification that was sent to the RAP at 120. The secret may be received in a variety of formats and either directly from the RAP or indirectly from the RAP in response to actions of the RAP with secure devices and/or services. Delivery may be simple or complex. Moreover, delivery itself may be driven by policy and communicated dynamically from the authorization acquisition service to the RAP.
- For example, at 131, the secret may be received as a touch tone response from a cell phone or communication device of the RAP in response to the notification. Alternatively, at 131, the secret may be received from a secure WWW service that the RAP access with a pass key, which upon access causes the WWW service to deliver the secret to the authorization acquisition service. In this latter case, the RAP may never know what the secret was and may not care, but the RAP and the RAP's credentials were needed to cause the secret to be delivered to the authorization acquisition service. In still another situation, at 131, the authorization acquisition service may receive the secret as a text message, as an email message, or event as a voice message (the voice message may be analyzed for voice pattern recognition associated with the RAP). Thus, biometrics may also be used to authenticate responses having the secret as being from the RAP. In another case, at 131, the authorization acquisition service may receive the secret directly from a secure device activated by the RAP in response to the request. So, the RAP may use a smart card or memory device to obtain or generate the secret and interface a reader or network interface to a network where the secret is obtained and sent either directly to the authorization acquisition service or to another service and then to the authorization acquisition service.
- In an embodiment, at 132, the authorization acquisition service may receive the secret as a random and/or optionally a time sensitive or dependent secret. So, the RAP may access a device or service to obtain the secret and then that secret is either communicated by the RAP or by another device or service to the authorization acquisition service. Examples of this were discussed above.
- At 140, the authorization acquisition service acquires the access key in response to a successfully received secret. That is, the secret serves itself as a key to unlock a secret store, service, or device, where the true access key is acquired.
- According to an embodiment, at 141, it may be that the lock box, secret store, service, or device that has the access key requires more than one secret from more than one RAP to open up and supply the desired access key. Thus, the authorization acquisition service may simultaneously perform the processing discussed with respect to 120-140, at 141, with one or more additional RAP's and may use the additional secret(s) to completely unlock and obtain the access key.
- It is noted, that in some cases the secret obtained, at 130, is the desired access key which is acquired, at 140. So, the RAP may directly supply the access key in cases where the secret is in fact the access key. Policy may notify the authorization acquisition service that the RAP is directly supplying the desired access key, such that the authorization acquisition service recognizes the secret obtained as the access key.
- At 150, the authorization acquisition service submits the access key to the security system for purposes of initiating the secure operation. It is noted that the access key may be regularly changing and using a mechanism to change that is known only to the secret store housing the access key and the security system. The secret store and the security system may then be time synchronized with one another, such that at any particular point in time both of them possess the same access key. The security system does not permit the secure operation to be initiated without the authorization acquisition service delivering a valid access key that authorizes the initiation of the secure operation within the security system.
- In an embodiment, at 151, the authorization acquisition service may, pursuant to policy, be required to acquire multiple access keys to successfully authenticate the secure operation for initiation within the security system. In such a case, the authorization acquisition service may concurrently or simultaneously perform the processing of 120-140, at 151 to acquire multiple different access keys, each of which are needed by the security system to permit the secure operation to proceed. Note that this is different from the processing at 141 in that multiple secrets from multiple RAP's at 141 were used to obtain a single access key; however, at 151, multiple secrets from multiple RAP's are used to obtain multiple access keys.
- As was mentioned above, a variety of the processing of the authorization acquisition service may be driven by policies. The policies may be predefined and configured within the authorization acquisition service or may be dynamically communicated and communicated in real time to the authorization acquisition service from the security system. Accordingly, in an embodiment, at 160, the processing at 120 and 140 may be driven in response to static or dynamic policies.
- The processing technique of the authorization acquisition service permits FIPS 140-2 security to occur with remote or roaming Crypto Officers that do not have to physically and geographically present at the security system to initiate a secure operation when needed. Additionally, the processing technique provides for enhanced security for authorizing any secure operation remotely in a geographically independent manner.
-
FIG. 2 is a diagram ofmethod 200 for remotely supplying a secret used to acquire the access key described with the processing of theFIG. 1 , according to an example embodiment. The method 200 (hereinafter “remote authorization principal (RAP) device service” is implemented in a machine-accessible and readable medium and is operational over a network. The network may be wired, wireless, or a combination of wired and wireless. - According to an embodiment, remote authorization principal device service interacts with the authorization acquisition service represented by the
method 100 to supply a secret that the authorization acquisition service uses to acquire an access key that is supplied to the security system to initiate the secure operation. - At 210, the RAP device service receives a request for a secret from a remote authorization acquisition service (RAAS), such as the RAAS represented by the
method 100 of theFIG. 1 . The RAP device service processes on a device that interacts with an RAP. According to an embodiment, the RAP is a FIPS 140-2 compliant Crypto Officer and the device that the RAP device service processes on is a cell phone or a voice-enabled communication device that interacts with and is operated by the RAP. Thus, in an embodiment, at 240, the RAP device service processes on a voice-enabled communication device, such as but not limited to a voice over the Internet Protocol (IP) (VoIP) phone, a cell phone, a satellite phone, etc. - According to an embodiment, at 211, the identity of the sources that have the secret may be unknown to the RAP device service before receipt of the request. That is, the request itself may identify the identity of the sources having the secret and may also identify the technique that the RAP device service is to use to acquire the secret from the one or more sources. Thus, a key may be provided to the RAP device service and that key unlocks a source and causes the source to produce the desired secret.
- In an embodiment, at 212, the RAP device service may also receive the request initially in a variety of disparate formats or a combination of formats and/or channels. So, the request may be received from the RAAS directly as a text message, an email, a voice message, or various combinations of these things. Alternatively, the request may be received indirectly from the RAAS via a service that the RAAS activates causing that service to raise an event or event code to the RAP device service.
- At 220, the RAP device service acquires a secret from one or more sources in response to the request received from the RAAS. This may occur in a variety of manners and via a variety of mechanisms. For example, at 221, the RAP device service may interface a device or service with the network to acquire the secret. That is, the RAP device service may activate or cause to be activated a device or service that supplies the secret over the network. The secret may be directly supplied back to the RAP device service or may be supplied to the RAAS independent of the RAP device service after the RAP device service caused the device or service to generate and/or produce the desired secret.
- As another example, at 222, the RAP device service may access a random secret generation device or service for purposes of acquiring the secret desired by the RAAS. The RAP device service may not know in advance the secret and may not ever know the secret if the random device or service directly delivers the produced or generated secret to the RAAS on behalf of the RAP device service.
- Once the secret is generated, at 230, the RAP device service causes the secret to be communicated to the RAAS. The RAP device service may directly supply this secret to the RAAS. Alternatively, the RAP device service may initiate and cause other devices or services to deliver the secret directly to the RAAS on behalf of the RAP device service. Example scenarios for this were discussed above.
- It is noted that acquiring the secret need not be complex and may be straightforward. So, for example, a source may be a Crypto Officer having information in his head that is acquired at 220 by that officer inputting it into a device that the RAP device service is processing on, such as a cell phone. The RAP device service may then directly supply the secret over the network to the RAAS at 230. Of course much more complicated and varied situations and processing may occur as was described above. It is also worthy to note that each request for a secret for even the same secure operation may be varied, such that the exact processing flow is random. In such cases, the processing at 211 permits the RAP device service to dynamically adjust and account for varying processing flows used to acquire the desired secret.
- Once the RAP device service delivers or causes to be delivered the secret, the processing of the RAAS uses the secret to acquire an access key from a secret store and delivers the access key to the security system. The security system then authenticates the access key and if verified initiates the secure operation within the security system. The processing with respect to the RAAS was described above with respect to the
method 100 of theFIG. 1 and some example processing of the security system is described below with respect to themethod 300 of theFIG. 3 . -
FIG. 3 is a diagram of amethod 300 for initiating a secure operation in response to the access key described with the processing of theFIG. 1 and obtained from the secret supplied with the processing of theFIG. 2 , according to an example embodiment. The method 300 (hereinafter “security system service” is implemented in a machine-accessible and readable medium and is operational over a network. The network may be wired, wireless, or a combination of wired and wireless. - According to an embodiment, the security system service represents processing of a security system that controls and determines whether a secure operation is initiated. The security system service interacts directly with the authorization acquisition service represented by the
method 100 of theFIG. 1 and indirectly with the remote authorization principal device service represented by themethod 200 of theFIG. 2 . The security system service may be implemented as a sub service or enhancement to an existing security system so that it is designed to interact with the authorization acquisition service (AAS), such as the AAS represented by themethod 100 of theFIG. 1 . - At 310, the security system service detects a request to initiate a secure operation within a security system. This can occur in a variety of manners. For example, there may be an attempt to boot up a device or services associated with the security system. The secure operation does not have to be a startup operation; that is, it may be a request to execute an operation that requires extraordinary security precautions. In a military situation this may be an operation that raises a threat level or that initiates some kind of strike. In other cases, the secure operation may actually be a shutdown of a running service or process. So, the secure operation can be any operation that requires or is associated with extraordinary authorization procedures before that secure operation is initiated within the security system.
- At 320, the security system service evaluates policy associated with authorizing the initiation. So, the security system being monitored by the security system service may include a variety of secure operations each of which may have different levels or security procedures. A policy may be associated with a single secure operation or a group of select secure operations. The policy may drive the processing flow and content of information communicated and expected by the security system service before any given secure operation is properly authenticated and initiated after a request to do the same is detected.
- At 330, the security system service makes a request to an AAS for an access key or set of access keys pursuant to instructions defined in the policy evaluated at 320. Thus, the policy may indicate that one or more access keys are needed to properly authenticate the request for initiating the secure operation and the security system service asks the AAS to attempt to acquire the access key or keys. If the AAS is unable to acquire the access key or keys then the secure operation will not be initiated. In some cases, the policy may put time limits on the elapsed amount of time for the AAS to deliver the access key or keys and if there is no delivery during that elapsed period of time, then any access key or keys delivered after that time will be ignored or considered void.
- According to an embodiment, at 331, the security system service may also include a variety of dynamic and real time information in the request to the AAS for the access key or keys. So, the security system service may actually identify the access key or keys that it needs to authenticate the secure operation. The identifier may identify a type or name for a given access key or access keys. The AAS may then be configured to identify specific RAPS in response to these identifiers and follow its own procedures for eventually acquiring the access key or keys. In a similar manner, the security system service may also identify a procedure for the AAS to follow in collecting the access key and that procedure may be randomly altered by the security system service. For example, a procedure may indicate which lock box or secret store that the AAS is to use to acquire the access key or keys and/or may indicate which random secret or key generation service a RAP should access to acquire a time-sensitive secret that the AAS may then use to access the secret store. A variety of procedures and processing flows may be embodied in the request from the security system service to the AAS. Each of which are intended to fall within the scope of the disclosure presented.
- The request made from the security system service to the AAS results in the AAS interacting with one or more RAP's in the manner discussed above with respect to the
method 100 of theFIG. 1 . The interactions of devices or services of the RAP were also described with respect to themethod 200 of the FIG. - 2.
- At 340, the security system service may receive a requested access key or keys from the AAS in response to successfully processing of the AAS to acquire secrets from one or more RAP's. The access keys or keys are then authorized or verified by the security system service and, assuming success, the secure operation is initiated within the security system.
- In an embodiment, at 350, the security system service may periodically synchronize with one or more secret stores to ensure the access key or keys are even more secure and non reproducible by intruders. For example, the security system service and a secret store may each randomly generate access keys on a regular basis (e.g., every 10 minutes). The security system service and the secret store may use the same random key generator and they may be clock synchronized with one another and periodically synchronize clocks with one another. So, the keys are never transferred between the two but clock or time settings are in a regular fashion. Thus, at any particular point in time, the security system service and the secret store are recognizing the same access key. It is also noted that the security system service may not have to store the access key, that is a hash for the access key or even the access key itself may be generated upon request. This provides for even greater security.
- In some cases, at 360, the security system service may supply the access key or keys to a secure loader for verification and for initiation of the secure operation. So, the verification of the access key and initiation of the secure operation may be further delegated to a secure service or module within the security system service.
- It is noted that the
methods methods FIGS. 1-3 , respectively. The media may be removable; such that when it is interfaced to the machine the instructions are uploaded to the machine and processed. The media may be prefabricated with the instructions within the machine within the memory and/or storage. Still further, the media may be associated with a remote network machine and downloaded to another processing machine for execution. -
FIG. 4 is a diagram of aremote authorization system 400, according to an example embodiment. Theremote authorization system 400 is implemented in a machine-accessible and readable medium and is accessed and processed over a network. The network may be wired, wireless, or a combination of wired and wireless. Theremote authorization system 400 implements, among other things, the authorization acquisition service represented by themethod 100 of theFIG. 1 . Moreover, theremote authorization system 400 interacts with the remote authorization principal device service represented by themethod 200 of theFIG. 2 and with the security system service represented by themethod 300 of theFIG. 3 . - The
remote authorization system 400 includes asecret store 401 and anauthorization acquisition service 402. Each of these will now be discussed in turn. - The
secret store 401 may be any secure hardware and/or software service that houses access keys or that is capable of producing access keys on demand. The access keys are consumed by a security system service, such as the security system service represented by themethod 300 of theFIG. 3 for purposes of authorizing the initiation of a secure operation. Furthermore, the access keys are acquired by the authorization acquisition service (AAS) 402 after theAAS 402 produces one or more secrets to access thesecret store 401. The secrets may themselves be considered keys, thus the terminology of secrets and keys may be used interchangeably herein and above. For purposes of illustration the terminology secrets have been used to distinguish what thesecret store 401 uses to unlock it versus what the security system uses to initiate the secure operation. - In an embodiment, the
secret store 401 may periodically and randomly update or change the access keys or the technique it uses to generate an access key on demand. This random technique is also know to the security system and the security system and thesecret store 401 time synchronize or clock synchronize with one another on a periodic bases to ensure that are any particular point in time that both thesecret store 401 and the security system have the same access key or set of access keys. - In yet another situation, the secrets used by the
AAS 402 to unlock thesecret store 401 may also be periodically and randomly updated or changed by both thesecret store 401 and security devices or services associated with or accessible to the RAP's. So, as an example, a RAP may have a random key or secret generator that is clock synchronized with thesecret store 401, such that at any particular point in time the secret generator will produce a random secret that thesecret store 401 will recognize as being valid. - The
AAS 402 interacts with three entities the security system, thesecret store 401, and RAP's. In some cases, interactions with the RAP's may result in other devices or services communicating with theAAS 402. For example, the actions or procedures of an RAP may result in a secure service, such as a secure WWW service, delivering a secret to theAAS 402. - The
AAS 402 receives authorization requests from the security system. Those requests may optionally include a variety of information, such as but not limited to, the identity of one or more RAP's, a procedure to use to acquire the desired access keys, the identity of one or moresecret stores 401, etc. It is also noted that some of this information may be preconfigured within theAAS 402, so the specifics as to how and where to get the access keys may be statically resolved or dynamically resolved or various combinations of both static and dynamic. Moreover, the procedures themselves may be random, such that no two situations for authorizing a same security operation within the security system uses a same access key, a samesecret store 401, a same RAP, and/or a same procedure that was used with a prior authorization of that security operation. - The
AAS 402, in response to authorization requests, sends notifications and other requests to one or more RAP's to acquire secrets that are used to open thesecret store 401 and acquire the access key or access keys. Examples of how these notifications occur were described in detail above with respect to the AAS represented by themethod 100 of theFIG. 1 . - Furthermore, the techniques for receiving the secrets and using the secrets to open the
secret store 401 were described in detail above with respect to the AAS represented by themethod 100 of theFIG. 1 . - Successful unlocking of the
secret store 401 produces the access key or keys, which theAAS 402 submits to the security system for purposes of initiating the secure operation within that security system. -
FIG. 5 is a diagram for example interactions that may occur for various components and techniques discussed with the example embodiments. - The diagram depicts a variety of components that interact with one another and include labels A-G representing data communication and interaction between the components.
- An example security system is shown in
FIG. 5 as a FIPS 140-2 Compliant System. It interacts direct with an authorization acquisition service via communication link A. So, the FIPS System may receive a resource to execute a secure operation such as the startup process labeled inFIG. 5 . Before the startup process is initiated, the FIPS Compliant System sends a request for an access key to the authorization acquisition service over A. - The authorization acquisition service then contacts authorizing entities or devices of the authorizing entities (referred to above as remote authorization principals and the remote authorization principal device service represented by the
method 200 of theFIG. 2 ). Examples of the authorization acquisition service were also provided above with respect to themethod 200 of theFIG. 2 and thesystem 400 of theFIG. 4 . It is also noted that the authorization acquisition service may be specialized, dedicated, and secure hardware with software designed to perform the features discussed herein or may be software operational on any secured hardware device, such as a proxy, firewall, gateway, etc. - The authorization acquisition service may include a policy or may be delivered a policy with the request for the access key via A. The policy informs the authorization acquisition service what secrets are needed and how they are to be obtained. It may be that more than one authorizing entity and more than one secret is needed for the authorization acquisition service to obtain the access key or keys from the lock box, or secret store. For example, link G depicts a situation where policy may dictate that two secrets from two separate authorizing entities are needed to unlock the lock box (secret store) and acquire the access key.
- In the example presented in
FIG. 5 , the authorizing entity may be contacted via a cellular, satellite, or mobile phone via communication link B by the authorization acquisition service. As mentioned above a different authorizing entity may also be contacted over link G. Assuming the device of the authorizing entity is a cell phone, then the authorizing entity may receive a request for the secret from the authorization acquisition service as a text message, a voice message, or combinations of text and voice messages. The request for the secret may include multiple messages to identify the situation to the authorizing entity, identity the FIPS System involved, identity the startup procedure, and perhaps identify a location as to where the authorizing entity may acquire the needed secret. - That is, the authorization acquisition service may actually instruct the authorizing entity where to acquire the secret it desires. For example, it may act the authorizing entity to use a smart card or other key generation technique via D and use that key to access a WWW service via E. The WWW service may then upon presentation of the key acquired via D send the secret to the authorization acquisition service via C. The techniques used by the first authorizing entity contacted via B may be the same or different then the techniques used by any needed second authorizing entity to supply its secret via G.
- A variety of permutations and processing scenarios may be used by the authorizing entity to directly or indirectly deliver the secret to the authorization acquisition service. For example, the authorizing entity may use touch tone codes to deliver the secret directly to the authorization acquisition service via B. It can be more complicated such that a random key is supplied to the authorizing entity either via B or via D and that random key gets the authorizing entity access to another service where the secret is obtained and either delivered directly to the authorizing entity for delivery via B or delivered on behalf of the authorizing entity via C.
- Once the secret or multiple secrets are obtained by the authorization acquisition service, the authorization acquisition service uses the secrets to access a secret store of lock box via F to acquire one or more access keys. These access keys are then supplied to the FIPS System via A. The FIPS System then uses the access key or keys to initiate the startup operation or supplies the access key or keys to a secure loader to initiate the startup process.
- The access keys themselves may be independently and randomly changing within the lock box and within the FIPS System. These changes may be temporal-based and/or entirely random. The lock box and the FIPS System are synchronized because they use the same mechanism and are time synchronized with one another such that when an access key changes it is changed on both the lock box and the FIPS System.
- One now fully appreciates how a secure and remote authorization technique may be implemented to authorize an operation of a security system. This technique complies with FIPS 140-2 and, among other things, may be used to eliminate the physical presence requirements of FIPS Crypto Officers without sacrificing security procedures.
- The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
- The Abstract is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
- In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/871,163 US8327417B2 (en) | 2006-03-29 | 2010-08-30 | Remote authorization for operations |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/392,195 US7810139B2 (en) | 2006-03-29 | 2006-03-29 | Remote authorization for operations |
US12/871,163 US8327417B2 (en) | 2006-03-29 | 2010-08-30 | Remote authorization for operations |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/392,195 Division US7810139B2 (en) | 2006-03-29 | 2006-03-29 | Remote authorization for operations |
Publications (2)
Publication Number | Publication Date |
---|---|
US20100325693A1 true US20100325693A1 (en) | 2010-12-23 |
US8327417B2 US8327417B2 (en) | 2012-12-04 |
Family
ID=38158143
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/392,195 Active 2029-08-05 US7810139B2 (en) | 2006-03-29 | 2006-03-29 | Remote authorization for operations |
US12/871,163 Expired - Fee Related US8327417B2 (en) | 2006-03-29 | 2010-08-30 | Remote authorization for operations |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/392,195 Active 2029-08-05 US7810139B2 (en) | 2006-03-29 | 2006-03-29 | Remote authorization for operations |
Country Status (3)
Country | Link |
---|---|
US (2) | US7810139B2 (en) |
EP (1) | EP1841181B1 (en) |
DE (1) | DE602007008632D1 (en) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7810139B2 (en) * | 2006-03-29 | 2010-10-05 | Novell, Inc | Remote authorization for operations |
US9665718B2 (en) | 2014-03-14 | 2017-05-30 | International Business Machines Corporation | Correlating a task with commands to perform a change ticket in an IT system |
US9654922B2 (en) | 2014-03-21 | 2017-05-16 | Venafi, Inc. | Geo-fencing cryptographic key material |
US9647998B2 (en) | 2014-03-21 | 2017-05-09 | Venafi, Inc. | Geo-fencing cryptographic key material |
US9531533B2 (en) | 2014-03-21 | 2016-12-27 | Venafi, Inc. | Rule-based validity of cryptographic key material |
US9686244B2 (en) * | 2014-03-21 | 2017-06-20 | Venafi, Inc. | Rule-based validity of cryptographic key material |
US9577823B2 (en) * | 2014-03-21 | 2017-02-21 | Venafi, Inc. | Rule-based validity of cryptographic key material |
US9680827B2 (en) | 2014-03-21 | 2017-06-13 | Venafi, Inc. | Geo-fencing cryptographic key material |
Citations (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4386233A (en) * | 1980-09-29 | 1983-05-31 | Smid Miles E | Crytographic key notarization methods and apparatus |
US5548721A (en) * | 1994-04-28 | 1996-08-20 | Harris Corporation | Method of conducting secure operations on an uncontrolled network |
US5742756A (en) * | 1996-02-12 | 1998-04-21 | Microsoft Corporation | System and method of using smart cards to perform security-critical operations requiring user authorization |
US5970149A (en) * | 1996-11-19 | 1999-10-19 | Johnson; R. Brent | Combined remote access and security system |
US5982892A (en) * | 1997-12-22 | 1999-11-09 | Hicks; Christian Bielefeldt | System and method for remote authorization for unlocking electronic data |
US6073237A (en) * | 1997-11-06 | 2000-06-06 | Cybercash, Inc. | Tamper resistant method and apparatus |
US6192405B1 (en) * | 1998-01-23 | 2001-02-20 | Novell, Inc. | Method and apparatus for acquiring authorized access to resources in a distributed system |
US6374355B1 (en) * | 1998-07-31 | 2002-04-16 | Lucent Technologies Inc. | Method for securing over-the-air communication in a wireless system |
US20020049912A1 (en) * | 2000-10-20 | 2002-04-25 | Shinsuke Honjo | Access control method |
US20020138771A1 (en) * | 2001-03-26 | 2002-09-26 | International Business Machines Corporation | System and method for maintaining user security features |
US20030033535A1 (en) * | 2000-01-27 | 2003-02-13 | Gwyn Fisher | Method and system for implementing a common user logon to multiple applications |
US6567793B1 (en) * | 1997-12-22 | 2003-05-20 | Christian Bielefeldt Hicks | Remote authorization for unlocking electronic data system and method |
US20030204722A1 (en) * | 2002-04-26 | 2003-10-30 | Isadore Schoen | Instant messaging apparatus and method with instant messaging secure policy certificates |
US6647494B1 (en) * | 1999-06-14 | 2003-11-11 | Intel Corporation | System and method for checking authorization of remote configuration operations |
US20040024764A1 (en) * | 2002-06-18 | 2004-02-05 | Jack Hsu | Assignment and management of authentication & authorization |
US20040101139A1 (en) * | 1998-10-16 | 2004-05-27 | Wack C. Jay | Cryptographic information and flow control |
US6772350B1 (en) * | 1998-05-15 | 2004-08-03 | E.Piphany, Inc. | System and method for controlling access to resources in a distributed environment |
US20040203592A1 (en) * | 2000-11-15 | 2004-10-14 | Motorola, Inc. | Introduction device, smart appliance and method of creating a federation thereof |
US20040243824A1 (en) * | 2003-05-28 | 2004-12-02 | Microsoft Corporation | Securely authorizing the performance of actions |
US20040250076A1 (en) * | 2003-05-23 | 2004-12-09 | Hsiang-Tsung Kung | Personal authentication device and system and method thereof |
US20050044378A1 (en) * | 2003-08-19 | 2005-02-24 | International Business Machines Corporation | Apparatus, system, and method for authorized remote access to a target system |
US20050068983A1 (en) * | 2003-09-30 | 2005-03-31 | Novell, Inc. | Policy and attribute based access to a resource |
US20050102509A1 (en) * | 2003-10-07 | 2005-05-12 | Koolspan, Inc. | Remote secure authorization |
US20050171872A1 (en) * | 2004-01-29 | 2005-08-04 | Novell, Inc. | Techniques for establishing and managing a distributed credential store |
US6934855B1 (en) * | 1998-10-13 | 2005-08-23 | Nds Limited | Remote administration of smart cards for secure access systems |
US6954740B2 (en) * | 2001-02-26 | 2005-10-11 | Albert Israel Talker | Action verification system using central verification authority |
US20050235352A1 (en) * | 2004-04-15 | 2005-10-20 | Staats Robert T | Systems and methods for managing a network |
US20050256878A1 (en) * | 2004-05-03 | 2005-11-17 | Research In Motion Limited | System and method for application authorization |
US20050257246A1 (en) * | 2004-04-30 | 2005-11-17 | Adams Neil P | System and method for configuring devices for secure operations |
US6993651B2 (en) * | 1999-12-08 | 2006-01-31 | Hewlett-Packard Development Company, L.P. | Security protocol |
US20060059539A1 (en) * | 2004-09-01 | 2006-03-16 | Oracle International Corporation | Centralized enterprise security policy framework |
US20060085652A1 (en) * | 2004-10-20 | 2006-04-20 | Zimmer Vincent J | Data security |
US20060099965A1 (en) * | 2004-11-10 | 2006-05-11 | Aaron Jeffrey A | Methods, systems and computer program products for remotely controlling wireless terminals |
US7099478B2 (en) * | 2001-09-05 | 2006-08-29 | Data Encryption Systems Limited | Apparatus for and method of controlling propagation of decryption keys |
US7240202B1 (en) * | 2000-03-16 | 2007-07-03 | Novell, Inc. | Security context sharing |
US7278023B1 (en) * | 2000-06-09 | 2007-10-02 | Northrop Grumman Corporation | System and method for distributed network acess and control enabling high availability, security and survivability |
US20070234406A1 (en) * | 2006-03-29 | 2007-10-04 | Novell, Inc. | Remote authorization for operations |
US7370351B1 (en) * | 2001-03-22 | 2008-05-06 | Novell, Inc. | Cross domain authentication and security services using proxies for HTTP access |
US7447494B2 (en) * | 2004-02-05 | 2008-11-04 | Xtreme Mobility, Inc. | Secure wireless authorization system |
US7577621B2 (en) * | 1999-09-20 | 2009-08-18 | Security First Corporation | Cryptographic server with provisions for interoperability between cryptographic systems |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9189777B1 (en) | 1999-09-20 | 2015-11-17 | Security First Corporation | Electronic commerce with cryptographic authentication |
-
2006
- 2006-03-29 US US11/392,195 patent/US7810139B2/en active Active
-
2007
- 2007-02-26 EP EP07103082A patent/EP1841181B1/en active Active
- 2007-02-26 DE DE602007008632T patent/DE602007008632D1/en active Active
-
2010
- 2010-08-30 US US12/871,163 patent/US8327417B2/en not_active Expired - Fee Related
Patent Citations (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4386233A (en) * | 1980-09-29 | 1983-05-31 | Smid Miles E | Crytographic key notarization methods and apparatus |
US5548721A (en) * | 1994-04-28 | 1996-08-20 | Harris Corporation | Method of conducting secure operations on an uncontrolled network |
US5742756A (en) * | 1996-02-12 | 1998-04-21 | Microsoft Corporation | System and method of using smart cards to perform security-critical operations requiring user authorization |
US5970149A (en) * | 1996-11-19 | 1999-10-19 | Johnson; R. Brent | Combined remote access and security system |
US6073237A (en) * | 1997-11-06 | 2000-06-06 | Cybercash, Inc. | Tamper resistant method and apparatus |
US5982892A (en) * | 1997-12-22 | 1999-11-09 | Hicks; Christian Bielefeldt | System and method for remote authorization for unlocking electronic data |
US7346583B2 (en) * | 1997-12-22 | 2008-03-18 | Christian Bielefeldt Hicks | Remote authorization for unlocking electronic data system and method |
US6567793B1 (en) * | 1997-12-22 | 2003-05-20 | Christian Bielefeldt Hicks | Remote authorization for unlocking electronic data system and method |
US6192405B1 (en) * | 1998-01-23 | 2001-02-20 | Novell, Inc. | Method and apparatus for acquiring authorized access to resources in a distributed system |
US6772350B1 (en) * | 1998-05-15 | 2004-08-03 | E.Piphany, Inc. | System and method for controlling access to resources in a distributed environment |
US6944777B1 (en) * | 1998-05-15 | 2005-09-13 | E.Piphany, Inc. | System and method for controlling access to resources in a distributed environment |
US6374355B1 (en) * | 1998-07-31 | 2002-04-16 | Lucent Technologies Inc. | Method for securing over-the-air communication in a wireless system |
US6934855B1 (en) * | 1998-10-13 | 2005-08-23 | Nds Limited | Remote administration of smart cards for secure access systems |
US20040101139A1 (en) * | 1998-10-16 | 2004-05-27 | Wack C. Jay | Cryptographic information and flow control |
US6647494B1 (en) * | 1999-06-14 | 2003-11-11 | Intel Corporation | System and method for checking authorization of remote configuration operations |
US7577621B2 (en) * | 1999-09-20 | 2009-08-18 | Security First Corporation | Cryptographic server with provisions for interoperability between cryptographic systems |
US6993651B2 (en) * | 1999-12-08 | 2006-01-31 | Hewlett-Packard Development Company, L.P. | Security protocol |
US20030033535A1 (en) * | 2000-01-27 | 2003-02-13 | Gwyn Fisher | Method and system for implementing a common user logon to multiple applications |
US7240202B1 (en) * | 2000-03-16 | 2007-07-03 | Novell, Inc. | Security context sharing |
US7278023B1 (en) * | 2000-06-09 | 2007-10-02 | Northrop Grumman Corporation | System and method for distributed network acess and control enabling high availability, security and survivability |
US20020049912A1 (en) * | 2000-10-20 | 2002-04-25 | Shinsuke Honjo | Access control method |
US20040203592A1 (en) * | 2000-11-15 | 2004-10-14 | Motorola, Inc. | Introduction device, smart appliance and method of creating a federation thereof |
US6954740B2 (en) * | 2001-02-26 | 2005-10-11 | Albert Israel Talker | Action verification system using central verification authority |
US7370351B1 (en) * | 2001-03-22 | 2008-05-06 | Novell, Inc. | Cross domain authentication and security services using proxies for HTTP access |
US20020138771A1 (en) * | 2001-03-26 | 2002-09-26 | International Business Machines Corporation | System and method for maintaining user security features |
US7099478B2 (en) * | 2001-09-05 | 2006-08-29 | Data Encryption Systems Limited | Apparatus for and method of controlling propagation of decryption keys |
US20030204722A1 (en) * | 2002-04-26 | 2003-10-30 | Isadore Schoen | Instant messaging apparatus and method with instant messaging secure policy certificates |
US20040024764A1 (en) * | 2002-06-18 | 2004-02-05 | Jack Hsu | Assignment and management of authentication & authorization |
US20040250076A1 (en) * | 2003-05-23 | 2004-12-09 | Hsiang-Tsung Kung | Personal authentication device and system and method thereof |
US20040243824A1 (en) * | 2003-05-28 | 2004-12-02 | Microsoft Corporation | Securely authorizing the performance of actions |
US20050044378A1 (en) * | 2003-08-19 | 2005-02-24 | International Business Machines Corporation | Apparatus, system, and method for authorized remote access to a target system |
US20050068983A1 (en) * | 2003-09-30 | 2005-03-31 | Novell, Inc. | Policy and attribute based access to a resource |
US20050102509A1 (en) * | 2003-10-07 | 2005-05-12 | Koolspan, Inc. | Remote secure authorization |
US20050171872A1 (en) * | 2004-01-29 | 2005-08-04 | Novell, Inc. | Techniques for establishing and managing a distributed credential store |
US7647256B2 (en) * | 2004-01-29 | 2010-01-12 | Novell, Inc. | Techniques for establishing and managing a distributed credential store |
US7447494B2 (en) * | 2004-02-05 | 2008-11-04 | Xtreme Mobility, Inc. | Secure wireless authorization system |
US20050235352A1 (en) * | 2004-04-15 | 2005-10-20 | Staats Robert T | Systems and methods for managing a network |
US20050257246A1 (en) * | 2004-04-30 | 2005-11-17 | Adams Neil P | System and method for configuring devices for secure operations |
US20050256878A1 (en) * | 2004-05-03 | 2005-11-17 | Research In Motion Limited | System and method for application authorization |
US20060059539A1 (en) * | 2004-09-01 | 2006-03-16 | Oracle International Corporation | Centralized enterprise security policy framework |
US20060085652A1 (en) * | 2004-10-20 | 2006-04-20 | Zimmer Vincent J | Data security |
US20060099965A1 (en) * | 2004-11-10 | 2006-05-11 | Aaron Jeffrey A | Methods, systems and computer program products for remotely controlling wireless terminals |
US20070234406A1 (en) * | 2006-03-29 | 2007-10-04 | Novell, Inc. | Remote authorization for operations |
US7810139B2 (en) * | 2006-03-29 | 2010-10-05 | Novell, Inc | Remote authorization for operations |
Non-Patent Citations (4)
Title |
---|
Entity Authentication Using Public Key Cryptography, Federal Information Processing Standards Publication, pp 1-50, FIPS PUB 196, 1997 * |
Entrust Cryptographic Module 6.0, FIPS 140-1 Validation Security Policy, Pierre Boucher, pp 1-16, Entrust, 2003 * |
SafeNet High Assurance 500/1000 Gateway Cryptographic Module, FIPS 140-2 Level-2 Validation, pp 1-22, SafeNet Inc., 2005 * |
VPN-1 NG with Application Intelligence, FIPS 140-2 Non-Proprietary Security Policy, Level 2 Validation, pp 1-30, Checkpoint Software Technologies Ltd, 2004 * |
Also Published As
Publication number | Publication date |
---|---|
EP1841181B1 (en) | 2010-08-25 |
US20070234406A1 (en) | 2007-10-04 |
EP1841181A2 (en) | 2007-10-03 |
DE602007008632D1 (en) | 2010-10-07 |
US8327417B2 (en) | 2012-12-04 |
EP1841181A3 (en) | 2007-11-28 |
US7810139B2 (en) | 2010-10-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8327417B2 (en) | Remote authorization for operations | |
EP1504561B1 (en) | Methods and systems for secure transmission of information using a mobile device | |
EP2368339B1 (en) | Secure transaction authentication | |
EP2834730B1 (en) | Secure authentication in a multi-party system | |
CA2751138C (en) | Transforming static password systems to become 2-factor authentication | |
US7697920B1 (en) | System and method for providing authentication and authorization utilizing a personal wireless communication device | |
CN101120569B (en) | Remote access system and method for user to remotely access terminal equipment from subscriber terminal | |
KR100621420B1 (en) | Network connection system | |
US20160337351A1 (en) | Authentication system | |
US20040097217A1 (en) | System and method for providing authentication and authorization utilizing a personal wireless communication device | |
US20050188219A1 (en) | Method and a system for communication between a terminal and at least one communication equipment | |
KR20080091382A (en) | A system, an arrangement and a method for end user authentication | |
CN103067399A (en) | A wireless transmitting/receiving unit | |
US7581111B2 (en) | System, method and apparatus for transparently granting access to a selected device using an automatically generated credential | |
US20170279798A1 (en) | Multi-factor authentication system and method | |
US11363014B2 (en) | Method and system for securely authenticating a user by an identity and access service using a pictorial code and a one-time code | |
US20220237282A1 (en) | Decentralized password vault | |
US11985242B2 (en) | Method and system for authenticating a user on a user device | |
EP3881208A1 (en) | Secure linking of device to cloud storage | |
US11416586B2 (en) | Secure communication application registration process | |
RU2395911C2 (en) | System, device and method for end user authentication |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, NEW YORK Free format text: GRANT OF PATENT SECURITY INTEREST;ASSIGNOR:NOVELL, INC.;REEL/FRAME:026270/0001 Effective date: 20110427 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, NEW YORK Free format text: GRANT OF PATENT SECURITY INTEREST (SECOND LIEN);ASSIGNOR:NOVELL, INC.;REEL/FRAME:026275/0018 Effective date: 20110427 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: NOVELL, INC., UTAH Free format text: RELEASE OF SECURITY IN PATENTS SECOND LIEN (RELEASES RF 026275/0018 AND 027290/0983);ASSIGNOR:CREDIT SUISSE AG, AS COLLATERAL AGENT;REEL/FRAME:028252/0154 Effective date: 20120522 Owner name: NOVELL, INC., UTAH Free format text: RELEASE OF SECURITY INTEREST IN PATENTS FIRST LIEN (RELEASES RF 026270/0001 AND 027289/0727);ASSIGNOR:CREDIT SUISSE AG, AS COLLATERAL AGENT;REEL/FRAME:028252/0077 Effective date: 20120522 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, AS COLLATERAL AGENT, NEW YORK Free format text: GRANT OF PATENT SECURITY INTEREST SECOND LIEN;ASSIGNOR:NOVELL, INC.;REEL/FRAME:028252/0316 Effective date: 20120522 Owner name: CREDIT SUISSE AG, AS COLLATERAL AGENT, NEW YORK Free format text: GRANT OF PATENT SECURITY INTEREST FIRST LIEN;ASSIGNOR:NOVELL, INC.;REEL/FRAME:028252/0216 Effective date: 20120522 |
|
CC | Certificate of correction | ||
AS | Assignment |
Owner name: NOVELL, INC., UTAH Free format text: RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 028252/0316;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:034469/0057 Effective date: 20141120 Owner name: NOVELL, INC., UTAH Free format text: RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 028252/0216;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:034470/0680 Effective date: 20141120 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNORS:MICRO FOCUS (US), INC.;BORLAND SOFTWARE CORPORATION;ATTACHMATE CORPORATION;AND OTHERS;REEL/FRAME:035656/0251 Effective date: 20141120 |
|
REMI | Maintenance fee reminder mailed | ||
AS | Assignment |
Owner name: MICRO FOCUS SOFTWARE INC., DELAWARE Free format text: CHANGE OF NAME;ASSIGNOR:NOVELL, INC.;REEL/FRAME:040020/0703 Effective date: 20160718 |
|
LAPS | Lapse for failure to pay maintenance fees | ||
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20161204 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT, NEW Free format text: NOTICE OF SUCCESSION OF AGENCY;ASSIGNOR:BANK OF AMERICA, N.A., AS PRIOR AGENT;REEL/FRAME:042388/0386 Effective date: 20170501 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., DELAWARE Free format text: SECURITY INTEREST;ASSIGNORS:ATTACHMATE CORPORATION;BORLAND SOFTWARE CORPORATION;NETIQ CORPORATION;AND OTHERS;REEL/FRAME:044183/0718 Effective date: 20170901 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT, NEW Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE TO CORRECT TYPO IN APPLICATION NUMBER 10708121 WHICH SHOULD BE 10708021 PREVIOUSLY RECORDED ON REEL 042388 FRAME 0386. ASSIGNOR(S) HEREBY CONFIRMS THE NOTICE OF SUCCESSION OF AGENCY;ASSIGNOR:BANK OF AMERICA, N.A., AS PRIOR AGENT;REEL/FRAME:048793/0832 Effective date: 20170501 |
|
AS | Assignment |
Owner name: NETIQ CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.), WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: ATTACHMATE CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: SERENA SOFTWARE, INC, CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS (US), INC., MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: BORLAND SOFTWARE CORPORATION, MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS LLC (F/K/A ENTIT SOFTWARE LLC), CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.), WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: MICRO FOCUS (US), INC., MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: NETIQ CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: ATTACHMATE CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: BORLAND SOFTWARE CORPORATION, MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 |