Best Practice Guidelines
SafeNet ProtectToolkit-C can be used to add cryptographic services to any application requiring such services in a standardized way. Cryptographic services are required where security policy exists, and must be enforced to the fullest possible extent by state of the art existing technology. Currently, cryptographic methods are the only way to assure authenticity, confidentiality and integrity to levels that can be mathematically shown to resist all known attacks for the foreseeable future.
Simplicity is another essential goal since complex systems are extremely difficult to analyze to an extent where all weakness can be found or shown not to exist to a level that is practicable. SafeNet ProtectToolkit-C is a simple and low-level key management and cryptographic service provider and its simplicity should allow it to be used easily to provide the necessary level of cryptographic service.
There are many independent, and sometimes conflicting, goals in the development life cycle of secure products, so this document shall outline the best approach to the use of SafeNet ProtectToolkit-C, always keeping these goals in mind. Above all, the developer should always strive to keep implementation simple.
The remainder of this document assumes a basic level of understanding of the SafeNet ProtectToolkit-C product and the PKCS#11 (Cryptoki) system. It refers to the PKCS#11 device as a security module and this may be a stand-alone appliance, or adapter-based PKCS#11 security module.
This chapter contains the following sections:
>Hierarchical Deterministic Wallets in SafeNet ProtectToolkit
Introduction
The best place to start building a SafeNet ProtectToolkit-C application is with the sample applications that demonstrate how the SafeNet ProtectToolkit-C system should be initialized and used to perform various cryptographic operations. Although the samples vary in complexity, they are all real working SafeNet ProtectToolkit-C utilities and cover all SafeNet ProtectToolkit-C services.
System security depends mainly on confidentiality, authentication, and access control.
Confidentiality
Confidentiality is critical when data must exist or be transferred through an environment where it may be vulnerable to inspection by an unauthorized person, and damages to the owner of the data may result from such inspection. The best way to protect confidential data is to encrypt it. Examples of confidential information include corporate or personal data, and cryptographic keys.
Integrity / Authentication
Integrity requires that no unauthorized person can alter data without detection. Integrity can be assured by using message authentication codes (MAC), a cryptographic digest of the message that requires knowledge of a secret key.
NOTE It is not necessary to know the value of a secret key to use it to encrypt or sign (MAC) something.
Access Control
Access to certain objects must be restricted to reliable people, or circumstances in which misuse can be easily detected . Access control demands accountability from those who interact with the data. It requires users to be authenticated before access is granted. There are many methods of user authentication.
Getting to Know SafeNet ProtectToolkit-C
To become proficient at SafeNet ProtectToolkit-C development, you must understand PKCS#11 and basic security and cryptographic principles. The entire PKCS (Public Key Cryptographic Standard) suite of standards is relevant, since PKCS#11 employs elements of most of the other PKCS standards. All the PKCS standard documentation can be found online.
You should also refer to PKCS#11 Command Reference, which details some of the many differences between the PKCS#11 standard and SafeNet ProtectToolkit-C.
The sample PKCS#11 application code included in the SDK installation is another excellent starting point for getting to know SafeNet ProtectToolkit-C. These applications may be compiled and inspected, or used directly for commercial PKCS#11 applications.
