[go: nahoru, domu]

US20100325693A1 - Remote authorization for operations - Google Patents

Remote authorization for operations Download PDF

Info

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
Application number
US12/871,163
Other versions
US8327417B2 (en
Inventor
Stephen R. Carter
Lloyd Leon Burch
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Micro Focus Software Inc
JPMorgan Chase Bank NA
Original Assignee
Novell Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Novell Inc filed Critical Novell Inc
Priority to US12/871,163 priority Critical patent/US8327417B2/en
Publication of US20100325693A1 publication Critical patent/US20100325693A1/en
Assigned to CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH reassignment CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH GRANT OF PATENT SECURITY INTEREST Assignors: NOVELL, INC.
Assigned to CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH reassignment CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH GRANT OF PATENT SECURITY INTEREST (SECOND LIEN) Assignors: NOVELL, INC.
Assigned to NOVELL, INC. reassignment NOVELL, INC. RELEASE OF SECURITY INTEREST IN PATENTS FIRST LIEN (RELEASES RF 026270/0001 AND 027289/0727) Assignors: CREDIT SUISSE AG, AS COLLATERAL AGENT
Assigned to NOVELL, INC. reassignment NOVELL, INC. RELEASE OF SECURITY IN PATENTS SECOND LIEN (RELEASES RF 026275/0018 AND 027290/0983) Assignors: CREDIT SUISSE AG, AS COLLATERAL AGENT
Assigned to CREDIT SUISSE AG, AS COLLATERAL AGENT reassignment CREDIT SUISSE AG, AS COLLATERAL AGENT GRANT OF PATENT SECURITY INTEREST SECOND LIEN Assignors: NOVELL, INC.
Assigned to CREDIT SUISSE AG, AS COLLATERAL AGENT reassignment CREDIT SUISSE AG, AS COLLATERAL AGENT GRANT OF PATENT SECURITY INTEREST FIRST LIEN Assignors: NOVELL, INC.
Publication of US8327417B2 publication Critical patent/US8327417B2/en
Application granted granted Critical
Assigned to NOVELL, INC. reassignment NOVELL, INC. RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 028252/0216 Assignors: CREDIT SUISSE AG
Assigned to NOVELL, INC. reassignment NOVELL, INC. RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 028252/0316 Assignors: CREDIT SUISSE AG
Assigned to BANK OF AMERICA, N.A. reassignment BANK OF AMERICA, N.A. SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ATTACHMATE CORPORATION, BORLAND SOFTWARE CORPORATION, MICRO FOCUS (US), INC., NETIQ CORPORATION, NOVELL, INC.
Assigned to MICRO FOCUS SOFTWARE INC. reassignment MICRO FOCUS SOFTWARE INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: NOVELL, INC.
Assigned to JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT reassignment JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT NOTICE OF SUCCESSION OF AGENCY Assignors: BANK OF AMERICA, N.A., AS PRIOR AGENT
Assigned to JPMORGAN CHASE BANK, N.A. reassignment JPMORGAN CHASE BANK, N.A. SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ARCSIGHT, LLC, ATTACHMATE CORPORATION, BORLAND SOFTWARE CORPORATION, ENTIT SOFTWARE LLC, MICRO FOCUS (US), INC., MICRO FOCUS SOFTWARE, INC., NETIQ CORPORATION, SERENA SOFTWARE, INC.
Assigned to JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT reassignment JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT 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. Assignors: BANK OF AMERICA, N.A., AS PRIOR AGENT
Assigned to MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.), NETIQ CORPORATION, MICRO FOCUS (US), INC., BORLAND SOFTWARE CORPORATION, ATTACHMATE CORPORATION reassignment MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.) RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251 Assignors: JPMORGAN CHASE BANK, N.A.
Assigned to NETIQ CORPORATION, MICRO FOCUS (US), INC., MICRO FOCUS LLC (F/K/A ENTIT SOFTWARE LLC), BORLAND SOFTWARE CORPORATION, ATTACHMATE CORPORATION, SERENA SOFTWARE, INC, MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.) reassignment NETIQ CORPORATION RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718 Assignors: JPMORGAN CHASE BANK, N.A.
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102Entity profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/081Additional 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

Techniques for the remote authorization of secure operations are provided. A secure security system restricts access to a secure operation via an access key. An authorization acquisition service obtains the access key on request from the secure security system when an attempt is made to initiate the secure operation. The authorization acquisition service gains access the access key from a secure store via a secret. That is, the secret store is accessible via the secret. The secret is obtained directly or indirectly from a remote authorization principal over a network.

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.
  • FIELD
  • The invention relates generally to security and more particularly to techniques for remote authorization for operations.
  • BACKGROUND
  • 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.
  • SUMMARY
  • 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.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • 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.
  • DETAILED DESCRIPTION
  • 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 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.
  • 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 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.
  • 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 the FIG. 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 the FIG. 1 and some example processing of the security system is described below with respect to the method 300 of the FIG. 3.
  • 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.
  • 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 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.
  • 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 the FIG. 1. The interactions of devices or services of the RAP were also described with respect to the method 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 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. Moreover, 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. Furthermore, 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.
  • 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 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.
  • In yet another situation, 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. So, as an example, 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.
  • 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. 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 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.
  • 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 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.
  • 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. 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)

1. A machine-implemented method to execute on a machine, comprising:
receiving, by the machine, a request for a secret from a remote authorization acquisition service, the secret is used to initiate an operation with a security system;
acquiring, by the machine, the secret from one or more sources; and
causing, by the machine, the secret to be communicated to the remote authorization acquisition service.
2. The method of claim 1, wherein receiving further includes identifying the one or more sources or identifying techniques to be used with the one or more sources from instructions that are included with the request.
3. The method of claim 1, wherein receiving further includes receiving the request via at least one of an event notification from a service activated by the remote authorization acquisition service, a text message sent from the remote authorization acquisition service, an email message sent from the remote authorization acquisition service, and a voice message sent from the remote authorization acquisition service.
4. The method of claim 1, wherein acquiring further includes interfacing a device having the secret to a network to acquire the secret.
5. The method of claim 1, wherein acquiring further includes accessing a random secret generation device or service to acquire the secret.
6. The method of claim 1 further comprising, processing the method on the machine that is a voice-enabled communication device that interacts with an authorization principal.
7. A machine-implemented method to execute on a machine, comprising:
detecting, by the machine, a request for initiating a secure operation;
evaluating, by the machine, a policy associated with authorizing the secure operation for initiation; and
making, by the machine, a request to an authorization acquisition service to acquire one or more access keys pursuant to the policy from one or more remote authorization principals.
8. The method of claim 7 further comprising, receiving and verifying, by the machine, the one more access keys, which are received from the authorization acquisition service in response to one or more secrets obtained from the one or more remote authorization principals.
9. The method of claim 7, wherein making further includes supplying one or more identifiers for the one or more access keys or supplying a procedure for acquiring the one or more access keys with the request to the authorization acquisition service.
10. The method of claim 7 further comprising, periodically synchronizing, by the machine, with a secret store to ensure the secret store has the one or more access keys, and wherein the secret store is accessed by the authorization acquisition service in response to one or more secrets obtained from the one or more remote authorization principals.
11. The method of claim 7 further comprising, supplying, by the machine, the one or more access keys successfully received from the authorization acquisition service to a secure loader, wherein the secure loader initiates the secure operation.
12. The method of claim 7, wherein detecting further includes detecting an attempt to boot up a particular device or particular service associated with a security system, which raises the request.
13. The method of claim 7, wherein detecting further includes detecting an attempt to shutdown a running service, which raises the request.
14. The method of claim 7, wherein making further includes voiding the one or more access keys when the authorization acquisition service fails to deliver the one or more access keys within a defined period of time included in the policy.
15. A machine-implemented method to execute on a machine, comprising:
receiving, by the machine, a request to initiate a secure operation within a secure system;
acquiring, by the machine, multiple keys from multiple different certified crypto officers, each crypto officer having one of the multiple keys and each crypt officer remotely communicating his/her key from a remote geographic location from that geographical location associated with the secure system;
using, by the machine, the multiple keys to acquire a secret from a secret store to initiate the secure operation; and
initiating, by the machine, the secure operation via the secret.
16. The method of claim 15, wherein acquiring further includes interacting with one crypto officers via a phone using voice instructions and interacting with another crypto officer via a phone using text messages to acquire the multiple keys.
17. The method of claim 15, wherein acquiring further includes identifying each of the certified crypto officers via a policy associated with the secure operation of the secure system.
18. The method of claim 15, wherein acquiring further includes using a policy that defines a particular mechanism for each certified crypto officer to deliver his/her key.
19. The method of claim 15, wherein acquiring further includes using a policy to instruct each of the certified crypt officers on how and where to obtain his/her key.
20. The method of claim 15, wherein using further includes randomly changing the secret within the secret store and configuring the secure operation to accept the changing secret.
US12/871,163 2006-03-29 2010-08-30 Remote authorization for operations Expired - Fee Related US8327417B2 (en)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9189777B1 (en) 1999-09-20 2015-11-17 Security First Corporation Electronic commerce with cryptographic authentication

Patent Citations (44)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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