Abstract: A method, computer system, and computer program product are provided for automatically analyzing software packages to identify the degree of differences between compared software packages and to apply security policies. A first software bill of materials for a software package is processed to extract a plurality of components of the software package, wherein the first software bill of materials indicates a first hierarchy of components based on relationships between components. The first hierarchy is compared to a second hierarchy, the second hierarchy corresponding to a second software bill of materials, to determine a degree of difference between the first hierarchy and the second hierarchy. The degree of difference is compared to one or more threshold values. A security policy is applied with respect to the software package according to a comparison of the degree of difference to the one or more threshold values.

Abstract: This technology uses a bootstrap key (“BSK”) to securely onboard a computing device to a network. A unique BSK associated with an onboarding computing device is used to verify for various deployment models (1) that the computing device has proof the computing device is connecting to the correct wired or wireless network and (2) that the network has proof the computing device is trusted. The BSK may be an associated BSK or an embedded BSK. A computing device receives a signed voucher from the manufacturer authorized signing authority (“MASA”) before the computing device may onboard to a network. The MASA will issue a voucher to a Bootstrapping Remote Secure Key Infrastructure (“BRSKI”) registrar if the registrar proves knowledge of the computing device's BSK to the MASA or the registrar has an established trust relationship with the MASA.

Abstract: A method includes establishing an application layer transport layer security (ATLS) connection between a network device and a cloud server by sending, from the network device, TLS records in transport protocol (e.g., HTTP) message bodies to the cloud server, the ATLS connection transiting at least one transport layer security (TLS) proxy device, receiving, from the cloud server via the ATLS connection, an identifier for a certificate authority, establishing a connection with the certificate authority associated with the identifier and, in turn, receiving from the certificate authority credentials to access an application service different from the cloud server and the certificate authority, and connecting to the application service using the credentials received from the certificate authority.

Abstract: This technology uses a bootstrap key (“BSK”) to securely onboard a computing device to a network. A unique BSK associated with an onboarding computing device is used to verify for various deployment models (1) that the computing device has proof the computing device is connecting to the correct wired or wireless network and (2) that the network has proof the computing device is trusted. The BSK may be an associated BSK or an embedded BSK. A computing device receives a signed voucher from the manufacturer authorized signing authority (“MASA”) before the computing device may onboard to a network. The MASA will issue a voucher to a Bootstrapping Remote Secure Key Infrastructure (“BRSKI”) registrar if the registrar proves knowledge of the computing device's BSK to the MASA or the registrar has an established trust relationship with the MASA.

Abstract: This technology uses a bootstrap key (“BSK”) to securely onboard a computing device to a network. A unique BSK associated with an onboarding computing device is used to verify for various deployment models (1) that the computing device has proof the computing device is connecting to the correct wired or wireless network and (2) that the network has proof the computing device is trusted. The BSK may be an associated BSK or an embedded BSK. A computing device receives a signed voucher from the manufacturer authorized signing authority (“MASA”) before the computing device may onboard to a network. The MASA will issue a voucher to a Bootstrapping Remote Secure Key Infrastructure (“BRSKI”) registrar if the registrar proves knowledge of the computing device's BSK to the MASA or the registrar has an established trust relationship with the MASA.

Abstract: In one embodiment, a device in a network receives node information regarding a plurality of nodes that are to join the network. The device determines network formation parameters based on the received node information. The network formation parameters are indicative of a network join schedule and join location for a particular node from the plurality of nodes. The device generates, according to the network join schedule, a join invitation for the particular node based on the network formation parameters. The join invitation allows the particular node to attempt joining the network at the join location via a specified access point. The device causes the sending of one or more beacons via the network that include the join invitation to the particular node. The particular node attempts to join the network via the specified access point based on the one or more beacons.

Abstract: This technology uses a bootstrap key (“BSK”) to securely onboard a computing device to a network. A unique BSK associated with an onboarding computing device is used to verify for various deployment models (1) that the computing device has proof the computing device is connecting to the correct wired or wireless network and (2) that the network has proof the computing device is trusted. The BSK may be an associated BSK or an embedded BSK. A computing device receives a signed voucher from the manufacturer authorized signing authority (“MASA”) before the computing device may onboard to a network. The MASA will issue a voucher to a Bootstrapping Remote Secure Key Infrastructure (“BRSKI”) registrar if the registrar proves knowledge of the computing device's BSK to the MASA or the registrar has an established trust relationship with the MASA.

Abstract: A root-of-trust of geolocation is provided for an apparatus that includes a trust anchor module with a cryptographic processor and a secure memory. The apparatus further includes a main processor coupled to the trust anchor module and configured to receive a digital geolocation certificate, the geolocation certificate including information identifying the apparatus, information regarding a physical location of the apparatus, information identifying an authorized entity that has verified the physical location of the apparatus, and a digital signature of the authorized entity. The main processor is further configured to cause the trust anchor module to store the digital geolocation certificate in the secure memory such that the digital geolocation certificate is cryptographically bound to the apparatus. The trust anchor module may also include, or otherwise communicate over a secure channel with, a movement sensor associated with the apparatus.

Abstract: A method includes establishing an application layer transport layer security (ATLS) connection between a network device and a cloud server by sending, from the network device, TLS records in transport protocol (e.g., HTTP) message bodies to the cloud server, the ATLS connection transiting at least one transport layer security (TLS) proxy device, receiving, from the cloud server via the ATLS connection, an identifier for a certificate authority, establishing a connection with the certificate authority associated with the identifier and, in turn, receiving from the certificate authority credentials to access an application service different from the cloud server and the certificate authority, and connecting to the application service using the credentials received from the certificate authority.

Abstract: In one implementation, a public key infrastructure utilizes a two stage revocation process for a set of data. One stage authenticates or revokes the set of data based on the status of the digital signature and another stage authenticates or revokes the set of data based on the status of an individual signature by the digital certificate. For example, a digital certificate based is assigned a certificate number. A serial number is assigned for a signature for the set of data as signed by the digital certificate. A data transmission, data packet, or install package includes the set of data, the certificate number and the serial number. Therefore, individual instances of the signature may be revoked according to serial number.

Abstract: A root-of-trust of geolocation is provided for an apparatus that includes a trust anchor module with a cryptographic processor and a secure memory. The apparatus further includes a main processor coupled to the trust anchor module and configured to receive a digital geolocation certificate, the geolocation certificate including information identifying the apparatus, information regarding a physical location of the apparatus, information identifying an authorized entity that has verified the physical location of the apparatus, and a digital signature of the authorized entity. The main processor is further configured to cause the trust anchor module to store the digital geolocation certificate in the secure memory such that the digital geolocation certificate is cryptographically bound to the apparatus. The trust anchor module may also include, or otherwise communicate over a secure channel with, a movement sensor associated with the apparatus.

Abstract: A method in an example embodiment includes creating an initial information package for a device attempting to join a network domain of a network environment; communicating the initial information package to a signing authority; sending an authorization token generated by the signing authority to the device, wherein the device validates the authorization token based on a credential in the device; and receiving an audit history report of the device, wherein the audit history report comprises information regarding previous attempts by the device to join the network environment.

Abstract: In one implementation, software components include an identity of a revocation authority. Prior to loading of the software in a given platform, the revocation authority is checked for any revocation messages. The revocation authority creates software component specific messages for any software components to be revoked, rather than using certificate revocation or individual licenses. The messages include mitigation information, such as instructions for automatically configuring already installed software without requiring an update or change in code.

Abstract: In one embodiment, a Manufacturer Installed Certificate (MIC) and a personal identification number are sent to a call controller to request a configuration profile. When the configuration file is received, the IP phone is provisioned according to the configuration profile.

Abstract: In one implementation, a public key infrastructure utilizes a two stage revocation process for a set of data. One stage authenticates or revokes the set of data based on the status of the digital signature and another stage authenticates or revokes the set of data based on the status of an individual signature by the digital certificate. For example, a digital certificate based is assigned a certificate number. A serial number is assigned for a signature for the set of data as signed by the digital certificate. A data transmission, data packet, or install package includes the set of data, the certificate number and the serial number. Therefore, individual instances of the signature may be revoked according to serial number.

Abstract: A method in an example embodiment includes creating an initial information package for a device attempting to join a network domain of a network environment; communicating the initial information package to a signing authority; sending an authorization token generated by the signing authority to the device, wherein the device validates the authorization token based on a credential in the device; and receiving an audit history report of the device, wherein the audit history report comprises information regarding previous attempts by the device to join the network environment.

Abstract: A method in an example embodiment includes creating an initial information package for a device in a domain of a network environment when the device is unconfigured. The method further includes communicating the initial information package to a signing authority, receiving an authorization token from the signing authority, and sending the authorization token to the unconfigured device, where the unconfigured device validates the authorization token based on a credential in the unconfigured device. In more specific embodiments, the initial information package includes a unique device identifier of the unconfigured device and a domain identifier of the domain. In further embodiments, the signing authority creates the authorization token by applying an authorization signature to the unique device identifier and the domain identifier. In other embodiments, the method includes receiving an audit history report of the unconfigured device and applying a policy to the device based on the audit history report.

Abstract: In one implementation, a public key infrastructure utilizes a two stage revocation process for a set of data. One stage authenticates or revokes the set of data based on the status of the digital signature and another stage authenticates or revokes the set of data based on the status of an individual signature by the digital certificate. For example, a digital certificate based is assigned a certificate number. A serial number is assigned for a signature for the set of data as signed by the digital certificate. A data transmission, data packet, or install package includes the set of data, the certificate number and the serial number. Therefore, individual instances of the signature may be revoked according to serial number.

Abstract: In an example embodiment, a key generation system (KGS) is used to generate private pairwise keys between peers belonging to a group. Each member of the group is provisioned with a set of parameters which allows each member to generate a key with any other member of the group; however, no group member can derive a key for pairings involving other group members. The private pairwise keys may be used to derive session keys between peers belonging to the group. Optionally, an epoch value may be employed to derive the private pairwise keys.

Abstract: In one implementation, software components include an identity of a revocation authority. Prior to loading of the software in a given platform, the revocation authority is checked for any revocation messages. The revocation authority creates software component specific messages for any software components to be revoked, rather than using certificate revocation or individual licenses. The messages include mitigation information, such as instructions for automatically configuring already installed software without requiring an update or change in code.