HP Open Source Security for OpenVMS Volume 1: Common Data Security Architecture > Chapter 5 CDSA Programming ConceptsCDSA Example Programs
Eight example programs are provided with CDSA on OpenVMS. Command procedures to build, sign, and install them are provided along with individual README files for each example. The following table lists the example programs and describes what aspect of CDSA each program is designed to convey.
Before you build the example programs, please read the following README files:
You must initialize CDSA before running any example program. See Chapter 2 for more information. Pay special attention to “Writing Signed Applications” if you plan to build one of the signed examples or are developing a CDSA add-in module. The examples are designed to be organized under a local build area or directory such as disk:[directory.example]. Define the rooted logical CDSA_TEMPDIR as disk:[directory.] using the following command:
Under this directory, the command procedures expect to find individual directories for each example; for example:
This example is a simple AES encryption/decryption program that uses CDSA, along with the necessary files to build it on OpenVMS. It consists of two source files (AES.C and DO_AES.C), and two build files (AES_BUILD.COM and AES.OPT). The AES example program can be built by copying the example files into a local build area, and executing the AES_BUILD command file, as follows:
The resulting AES.EXE file can be run as a foreign command. This can be set up by entering the following command:
You can then execute the program with the following options:
For example, to encrypt MYFILE.TXT using an ascii key with the AES example program, issue the following command:
To decrypt the same file, enter the following command:
To encrypt/decrypt using a hexadecimal key, use a key length of exactly 64 typed characters (32 hex bytes), and the -h switch as follows:
To change this example to a 128 or 192 bit AES example, perform the following steps.
This example is a simple DES encryption/decryption program that uses CDSA with no integrity checking. It links explicitly against CDSA$INCSSM300_SHR.EXE. The DES example includes two source files (DES.C and DO_DES.C) and two build files (BUILD_DES.COM and DES.OPT). Copy the example files into a local build area and then execute the BUILD_DES command file, as follows:
It is easiest to run the resulting DES.EXE file as a foreign command. Define a symbol for this command as follows:
You can now execute the program using any of the following applicable options:
For example, to encrypt MYFILE.TXT using an ASCII key with the DES example program, enter the following command using double quotation marks, as shown, if the key is case sensitive:
To decrypt the same file, enter the following command:
To encrypt or decrypt with a hexadecimal key, use the -h option and make sure the key length is exactly 16 typed characters (8 hexadecimal bytes). No quotation marks, either single or double, are allowed. For example:
This program uses some of the MDS and CSSM services of CDSA, with no integrity checking. It links explicitly against CDSA$INCSSM300_SHR.EXE. The MDS example includes one source file (MDS_EXAMPLE.C) and two build files (BUILD_MDS_EXAMPLE.COM and MDS_EXAMPLE.OPT). The program follows the descriptions and code fragments from the Intel Common Data Security Architecture Application Developer's Guide. Build the MDS example program by copying the example files into a local build area and then executing the BUILD_MDS_EXAMPLE command file, as follows:
The resulting MDS_EXAMPLE.EXE file takes no parameters and can be executed as follows:
The following is an excerpt of output from the program:
The DES2 example program is nearly identical to the DES example except that it uses integrity checking in addition to the encryption/decryption CDSA calls. It links explicitly against CDSA$INCSSM300_SHR.EXE. This example is designed to be signed using the CDSA signing tools. The necessary files to build the example on OpenVMS are included, with the exception of APPSELFKEY.H. This include file must be generated from the certificate created for the application. See “Writing Signed Applications” for complete instructions. A signed CDSA application will not execute until the proper credentials are generated. After you generate the application credentials and the include file, APPSELFKEY.H, you can build the DES2 example program by copying the example files into a local build area and executing the DES2_BUILD command file, as follows:
The resulting image, DES2.EXE, must be signed. On the signing system, run the following command procedure to generate the manifest:
Finally, on the development system, run the command procedure to install the module, as follows:
It is easiest to run the application DES2.EXE file as a foreign command. Define a symbol for this command as follows:
The options and program usage are the same as for the DES example. The DES3 example program is nearly identical to the DES2 example except that it links dynamically at run-time against CDSA$INCSSM300_SHR.EXE using the CDSA Application Adaption Layer. This example is designed to be signed using the CDSA signing tools. The files necessary to build the example on OpenVMS are included, with the exception of APPSELFKEY.H. This include file must be generated from the certificate created for the application. See “Writing Signed Applications” for complete instructions on writing a signed application. A signed CDSA application will not execute until the proper credentials are generated. After you generate the application credentials and the include file APPSELFKEY.H, you can build the DES3 example program by copying the example files into a local build area and executing the DES3_BUILD command file, as follows:
The resulting image, DES3.EXE, must be “signed”. On the signing system, run the following command procedure to generate the manifest:
Finally, on the development system, run the command procedure to install the module, as follows:
It is easiest to run the resulting DES3.EXE file as a foreign command. Define a symbol for this command as follows:
The options and usage of the program are the same as for the DES example. The ADDIN example shows how to provide a new add-in for an existing category of service. This CDSA example is an add-in (plug-in) module written to the CDSA CSP service provider interface with integrity checking. The add-in would be “loaded” and “attached” by an application, as in the DES examples, using CSSM_ModuleLoad(), CSSM_ModuleAttach(), and so forth. This example demonstrates the mechanics of developing a CDSA add-in module, which is a shareable image on OpenVMS. This example also provides the CDSA code files that are necessary to build an add-in module. The installation procedure registers the module in the CDSA MDS database, including its credentials, properties, and capability attributes. It attaches the module and executes RegisterCDSAModule() (the definition of INSTALL_ENTRY_NAME). The files necessary to build the example on OpenVMS are included, with the exception of MODSELFKEY.H. This include file must be generated from the certificate created for the add-in module. See “Writing Signed Applications” for complete instructions on writing a signed application. A signed CDSA application will not execute until the proper credentials are generated. After you generate the application credentials and the include file MODSELFKEY.H, you can build the ADDIN example program by copying the example files to a local build directory and executing the ADDIN_BUILD command file, as follows:
The resulting shareable image, STUBCSP300_SHR.EXE, must be signed. On the signing system, run the following command procedure to generate the manifest:
Finally, on the development system, run the command procedure to install the module, as follows:
The add-in module is now ready to be invoked by an application program. The DUMMYEMM and DUMMYEMMADDIN programs together demonstrate how to provide a new category of service for CDSA. DUMMYEMM, an elective module manager (EMM), contains the logic for handling the generic types of operations for the new service, and the add-in (DUMMYEMMADDIN) contains logic that is specific to the particular operation being performed. The ADDIN example (see the “ADDIN Example Program”) shows how to provide a new add-in for an existing category of service. DUMMYEMM and DUMMYEMMADDIN are designed to provide an entirely new category of service. This CDSA example is an elective module manager (EMM) that extends the functionality of CDSA by providing an additional category of service. The example defines a new service provider interface (SPI) with integrity checking. The purpose of this example is to demonstrate the mechanics of developing a CDSA EMM, which is a shareable image on OpenVMS. The example also provides the CDSA code files that are necessary to build an EMM. The installation procedure registers the module in the CDSA MDS database, including its credentials, properties, and capability attributes. It attaches the module and executes RegisterCDSAModule() (the definition of INSTALL_ENTRY_NAME). The files necessary to build the example on OpenVMS are included, with the exception of MODSELFKEY.H. This include file must be generated from the certificate created for the add-in module. Refer to “Writing Signed Applications” for complete instructions on writing a signed application. A signed CDSA application will not execute until the proper credentials are generated. After you generate the application credentials and the include file MODSELFKEY.H, you can build the DUMMYEMM example program by copying the example files to a local build directory and executing the DUMMYEMM_BUILD command file, as follows:
The resulting shareable image, DUMMYEMM_SHR.EXE, must be signed. On the signing system, run the following command procedure to generate the manifest:
Finally, on the development system, run the command procedure to install the module, as follows:
When an application program loads an add-in module that is written to the SPI of this EMM, the EMM will be automatically loaded. This CDSA example is an elective module manager (EMM) that extends the functionality of CDSA by providing an additional category of service. It provides an add-in module with integrity checking, written to the SPI made available by the DUMMYEMM example. The purpose of this example is to demonstrate the mechanics of developing a CDSA service provider module for a category of service defined by an EMM. It also provides the necessary CDSA code files that are necessary to build the module. The installation procedure registers the module in the CDSA MDS database, including its credentials, properties, and capability attributes. It attaches the module and executes RegisterCDSAModule() (the definition of INSTALL_ENTRY_NAME). The files necessary to build the example on OpenVMS are included, with the exception of MODSELFKEY.H. This include file must be generated from the certificate created for the add-in module. See “Writing Signed Applications” for complete instructions on writing a signed application. A signed CDSA application will not execute until the proper credentials are generated. After you generate the application credentials and the include file MODSELFKEY.H, you can build the DUMMYEMMADDIN example program by copying the example files to a local build area and executing the DUMMYEMMADDIN_BUILD command file, as follows:
The resulting shareable image, DUMMYEMMADDIN_SHR.EXE, must be signed. On the signing system, run the following command procedure to generate the manifest:
Finally, on the development system, run the command procedure to install the module, as follows:
The add-in module is now ready to be invoked by an application program. |