We take for granted the security of the systems we interact with daily. From checking emails to doing personal banking, to engaging in online commerce and end-to-end messaging, to command centers communications, field operations, satellite communications and digital signatures, each activity requires a high degree of trust.
While cybersecurity is a broad topic, this blog post focuses on one foundational technology of Zero Trust: cryptography.
The January 2022 Executive Office of the President memorandum on moving the U.S. government toward Zero Trust cybersecurity principles introduces the transition to Zero Trust with this statement: “We must verify anything and everything attempting to establish access.”
The keyword in that statement is “verify.”
Before entering your username to verify your identity to a system, your browser made a connection to that system. Your browser has verified the system it was talking to is the intended one. The browser used its own trust store, containing a list of digital certificates known as Certificate Authorities, to verify the signature of that remote system.
Your system then established a secure connection, and all messages exchanged thereafter were verified to ensure they had not been tampered with, using Transport Layer Security or TLS. That system, of course, needs to connect to other systems in the backend – verifying trust with all interconnected systems.
The applications and programs that run on these systems must be legitimate ones. For this, the authors of these programs have applied a digital signature on the files being executed. The operating system verifies the signature against its own trust store. To verify that its own trust store has not been tampered with, it signs its own updates and verifies them against a Root-of-Trust.
It’s all about signature generation and signature verification to establish this trust.
When Dell ships servers supporting the feature, we create a footprint of hardware and firmware components shipped, prior to leaving our assembly factory. Customers can then verify the servers they receive do not have parts or firmware modified, removed or added by using Dell Secure Component Verification, which relies on cryptographic signatures.
Whether it is usernames or passwords being encrypted in a system, secure communications between systems or the validation of software, firmware and hardware components, each shares the same foundation: cryptography.
Cryptography must also be verified to ensure proper implementation. This verification, or validation, comes from the issuance of a Federal Information Processing Standards 140 certificate, FIPS 140, issued by the Cryptographic Module Validation Program (CMVP).
This is where Dell BSAFE™ comes into play. The Dell BSAFE portfolio has a long history in the field of cryptography, with one major priority: maintaining FIPS 140 validation of our cryptographic software modules. BSAFE Software Development Kits for C and Java™ provide cryptographic implementations of major algorithms, as well as TLS capabilities required to build secure and trusted applications.
BSAFE cryptographic modules are FIPS 140-2 validated and have also been submitted to CMVP for FIPS 140-3 validation. Whether the toolkits are to be embedded in a system for distribution, in an embedded device, sent to space or underwater or used internally for business operations, they help enable a trusted foundation for an organizations’ Zero Trust journey.
Another advantage of using BSAFE cryptographic toolkits is that customers receive embargoed disclosure of security advisories prior to being made public, thus helping to prevent products or business operations from being caught by surprise by a sudden public security advisory.
Source: dell.com
Posts
0 comments:
Post a Comment