Abstract: In an example embodiment, a user interface is presented for interacting with a trust map identifying trust relationships between clients/users and servers/hosts. The trust relationships are defined by public/private key pairs in Secure Shell (SSH), Secure File Transfer Protocol (SFTP), Transport Layer Security/Secure Sockets Layer (TLS/SSL), Secure Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPsec), and so forth. A selected entity such as a server, client, client/server, key set, policy, and so forth is selected and displayed at the center of a hub/spoke diagram. Non-selected entities having a trust relationship with the hub entity are displayed as spokes. Similar spoke entitles may be grouped together. Trust relationships and related properties are displayed as lines between the hub and spoke entities. A user performs actions on the entities by manipulation of the hub, spoke, trust relationship and related user interface elements.

Abstract: In an example embodiment, a user interface is presented for interacting with a trust map identifying trust relationships between clients/users and servers/hosts. The trust relationships are defined by public/private key pairs in Secure Shell (SSH), Secure File Transfer Protocol (SFTP), Transport Layer Security/Secure Sockets Layer (TLS/SSL), Secure Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPsec), and so forth. A selected entity such as a server, client, client/server, key set, policy, and so forth is selected and displayed at the center of a hub/spoke diagram. Non-selected entities having a trust relationship with the hub entity are displayed as spokes. Similar spoke entitles may be grouped together. Trust relationships and related properties are displayed as lines between the hub and spoke entities. A user performs actions on the entities by manipulation of the hub, spoke, trust relationship and related user interface elements.

Abstract: In representative embodiments keys used in authentication are removed from local systems and stored on a key server system. When keys are needed for authentication, requests are routed to the key server system. In some embodiments, the keys do not leave the key server system and the key server system performs requested operations using the keys. In other embodiments, secure protocols are used to temporarily allow the local system to retrieve and use the key. In this latter situation, keys are not maintained on the local system.

Abstract: In an example embodiment, a user interface is presented for interacting with a trust map identifying trust relationships between clients/users and servers/hosts. The trust relationships are defined by public/private key pairs in Secure Shell (SSH), Secure File Transfer Protocol (SFTP), Transport Layer Security/Secure Sockets Layer (TLS/SSL), Secure Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPsec), and so forth. A selected entity such as a server, client, client/server, key set, policy, and so forth is selected and displayed at the center of a hub/spoke diagram. Non-selected entities having a trust relationship with the hub entity are displayed as spokes. Similar spoke entitles may be grouped together. Trust relationships and related properties are displayed as lines between the hub and spoke entities. A user performs actions on the entities by manipulation of the hub, spoke, trust relationship and related user interface elements.

Abstract: Example embodiments include centralized systems for managing cryptographic keys and trust relationships among systems. Embodiments may include a centralized key store and a centralized policy store. Key sets comprising public/private keys may be stored in or identified by key objects. Key objects within the key store may be organized into trust sets and policies may apply at any level within the key store. Policies may identify when to rotate key sets. When rotating key sets, a new public key and a new private key may be generated. The new public/private keys may be installed at locations where the old public/private keys reside. As the new public/private keys are installed, they may be tested. If problems with the new public/private keys occur, the new public/private keys may be rolled back to the old public/private keys for locations experiencing problems. Remedial action may then be taken to resolve the problems.

Abstract: In an example embodiment, a user interface is presented for interacting with a trust map identifying trust relationships between clients/users and servers/hosts. The trust relationships are defined by public/private key pairs in Secure Shell (SSH), Secure File Transfer Protocol (SFTP), Transport Layer Security/Secure Sockets Layer (TLS/SSL), Secure Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPsec), and so forth. A selected entity such as a server, client, client/server, key set, policy, and so forth is selected and displayed at the center of a hub/spoke diagram. Non-selected entities having a trust relationship with the hub entity are displayed as spokes. Similar spoke entitles may be grouped together. Trust relationships and related properties are displayed as lines between the hub and spoke entities. A user performs actions on the entities by manipulation of the hub, spoke, trust relationship and related user interface elements.

Abstract: In representative embodiments keys used in authentication are removed from local systems and stored on a key server system. When keys are needed for authentication, requests are routed to the key server system. In some embodiments, the keys do not leave the key server system and the key server system performs requested operations using the keys. In other embodiments, secure protocols are used to temporarily allow the local system to retrieve and use the key. In this latter situation, keys are not maintained on the local system.

Abstract: In an example embodiment, a user interface is presented for interacting with a trust map identifying trust relationships between clients/users and servers/hosts. The trust relationships are defined by public/private key pairs in Secure Shell (SSH), Secure File Transfer Protocol (SFTP), Transport Layer Security/Secure Sockets Layer (TLS/SSL), Secure Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPsec), and so forth. A selected entity such as a server, client, client/server, key set, policy, and so forth is selected and displayed at the center of a hub/spoke diagram. Non-selected entities having a trust relationship with the hub entity are displayed as spokes. Similar spoke entitles may be grouped together. Trust relationships and related properties are displayed as lines between the hub and spoke entities. A user performs actions on the entities by manipulation of the hub, spoke, trust relationship and related user interface elements.

Abstract: Example embodiments include centralized systems for managing cryptographic keys and trust relationships among systems. Embodiments may include a centralized key store and a centralized policy store. Key sets comprising public/private keys may be stored in or identified by key objects. Key objects within the key store may be organized into key sets and trust sets. Policies may apply at any level within the key store. Policies and associated keys may be grouped and organized to manage groups of keys according to common policies and to present complex relationships to a user. Lower level keys may inherit policy properties from higher levels. Higher levels may be locked to preclude changes at lower levels. Policies may include a variety of properties/fields to facilitate key management. Policies may determine what actions are taken with respect to a key or group of keys.

Abstract: In an example embodiment, a user interface is presented for interacting with a trust map identifying trust relationships between clients/users and servers/hosts. The trust relationships are defined by public/private key pairs in Secure Shell (SSH), Secure File Transfer Protocol (SFTP), Transport Layer Security/Secure Sockets Layer (TLS/SSL), Secure Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPsec), and so forth. A selected entity such as a server, client, client/server, key set, policy, and so forth is selected and displayed at the center of a hub/spoke diagram. Non-selected entities having a trust relationship with the hub entity are displayed as spokes. Similar spoke entitles may be grouped together. Trust relationships and related properties are displayed as lines between the hub and spoke entities. A user performs actions on the entities by manipulation of the hub, spoke, trust relationship and related user interface elements.

Abstract: Example embodiments include centralized systems for managing cryptographic keys and trust relationships among systems. Embodiments may include a centralized key store and a centralized policy store. Key sets comprising public/private keys may be stored in or identified by key objects. Key objects within the key store may be organized into trust sets and policies may apply at any level within the key store. Policies may identify when to rotate key sets. When rotating key sets, a new public key and a new private key may be generated. The new public/private keys may be installed at locations where the old public/private keys reside. As the new public/private keys are installed, they may be tested. If problems with the new public/private keys occur, the new public/private keys may be rolled back to the old public/private keys for locations experiencing problems. Remedial action may then be taken to resolve the problems.

Abstract: Example embodiments include centralized systems for managing cryptographic keys and trust relationships among systems. Embodiments may include a centralized key store and a centralized policy store. Key sets comprising public/private keys may be stored in or identified by key objects. Key objects within the key store may be organized into key sets and trust sets. Policies may apply at any level within the key store. Policies and associated keys may be grouped and organized to manage groups of keys according to common policies and to present complex relationships to a user. Lower level keys may inherit policy properties from higher levels. Higher levels may be locked to preclude changes at lower levels. Policies may include a variety of properties/fields to facilitate key management. Policies may determine what actions are taken with respect to a key or group of keys.

Abstract: Example embodiments include centralized systems for managing cryptographic keys and trust relationships among systems. The centralized systems may create rich search criteria that can be used to search managed systems for key information. The search criteria may be coupled with a tag to assign key information that meets the search criteria and a state to indicate at least one action that may be taken with regard to the search criteria. Agents located on managed systems may receive the search criteria, tag and state, and may implement the search. Alternate embodiments may access file or other operations on managed systems directly from the centralized system. Embodiments may include a centralized key store, a centralized policy store and/or a centralized configuration store. Key objects within the key store may be organized into trust sets and policies may apply at any level within the key store.