RSA BSAFE® Crypto-C Micro Edition 4.1.
Copyright and Trademark Notice and Trademarks Copyright © 2019 Dell Inc. or its subsidiaries. All rights reserved. Dell believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS”. DELL INC.
Migration Guide Contents Preface .................................................................................................................................... 1 Document Organization ...................................................................................................... 2 Related Documentation....................................................................................................... 3 Support and Service .....................................................................
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Chapter 5: Cryptographic API Changes ................................................................ 41 Pseudo-random Number Generation................................................................................. 42 Symmetric Key Encryption Cryptographic Objects ......................................................... 44 Initialization Vector Generation ................................................................................
Migration Guide Preface This document describes changes made in the RSA BSAFE Crypto-C Micro Edition (Crypto-C ME) toolkit, and the changes required when migrating applications between Crypto-C ME 3.x and Crypto-C ME 4.1.4. This guide is intended for use by software developers already familiar with their version of Crypto-C ME, and who intend to migrate their applications to Crypto-C ME 4.1.4. Developers should be familiar with: • C or C++ programming.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Document Organization This guide is organized into the following chapters: 2 • Chapter 1 Library and Header File Changes describes the library file, library initialization, and header file changes. • Chapter 2 Multithreading Support describes the thread locking model. • Chapter 3 Resource Management describes the resource management changes. • Chapter 4 Hardware Support describes the hardware support changes.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Related Documentation The Crypto-C ME documentation suite includes: • This document, the RSA BSAFE Crypto-C Micro Edition Migration Guide, in Portable Document Format (PDF), which describes changes made in the Crypto-C ME 4.1.4 toolkit, and the changes required to migrate existing applications, between Crypto-C ME 3.x and Crypto-C ME 4.1.4. • RSA BSAFE Crypto-C Micro Edition Release Notes, in PDF, with the latest information on Crypto-C ME.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Support and Service Access community and support information for your RSA BSAFE products on RSA Link at https://community.rsa.com/community/products/bsafe. RSA Link offers a knowledge base containing answers to common questions and solutions to known problems, product documentation, community discussions, and case management. Customers can also open support cases by sending an email to support@rsa.com. RSA Ready at https://community.rsa.
Migration Guide 1 Library and Header File Changes Crypto-C ME 4.1.4 includes library file, library initialization, memory management, and header file changes that need to be incorporated into your applications when migrating from Crypto-C ME 3.x.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide New Library Files Crypto-C ME 4.0 introduced a provider model, resulting in changed library files an application must link to. There are now four static library files an application can link to depending on the functionality required (the names differ depending on the platform): • ccme_core. The main library containing the generic functions and • ccme_swprov.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Migrate FIPS 140-2 Applications Applications using FIPS 140-2-compliant cryptographic functionality, which previously linked against the cryptocme_fips140 library file, now link against the ccme_core, and ccme_fipsprov library files. For PKCS #11 cryptographic functionality, which was previously available in the cryptocme_fips140 library file, applications must also link against the ccme_p11prov library file.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Memory Management Crypto-C ME 4.0 introduced improvements to the memory model to give applications full memory management control within the Crypto-C ME libraries. All memory is now managed using R_MEM memory allocator objects, which must be supplied from the application.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Library Initialization Crypto-C ME 4.0 introduced explicit library initialization and cleanup. A new function, R_STATE_init(), configures the low-level memory allocator that is required for other interfaces to work correctly. R_STATE_cleanup() releases any internal state after the application is finished with the library. Every call to R_STATE_init() requires a corresponding call to R_STATE_cleanup().
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Header File Changes All of the Crypto-C ME 4.1.4 public headers have been namespaced into a bsafe directory to avoid conflicts with other libraries. When migrating an application from Crypto-C ME 3.x to 4.1.4, you must either: • Update the #include directives and prefix each header file name with bsafe. RSA recommends this option. • Add the bsafe sub-directory as an additional include path to the compiler.
Migration Guide 2 Multithreading Support Crypto-C ME 4.1.4 has a more scalable and flexible thread locking model that needs to be incorporated into your applications when migrating from Crypto-C ME 3.x.
RSA BSAFE Crypto-C Mcro Edition 3.x to 4.1.4 Migration Guide Lock Management The library now manages locks internally and the application needs to provide the synchronization method used. Crypto-C ME 4.1.4 provides a default locking implementation for all supported platforms using R_SYNC_METH_default(). Alternatively, custom implementations can be used.
RSA BSAFE Crypto-C Mcro Edition 3.x to 4.1.4 Migration Guide /* Perform cryptographic operations */ R_LIB_CTX_free(lib_ctx); for (i = 0; i < locks; ++i) { /* free lock i */ } free(locks); return 0; } Default Locking Implementation - Crypto-C ME 4.1.
RSA BSAFE Crypto-C Mcro Edition 3.x to 4.1.
Migration Guide 3 Resource Management Prior to Crypto-C ME 4.0.1, resources were managed as a static list supplied to the library context at the time of creation. This made it difficult for an application to use resources from different sources such as from PKCS #11 and software libraries, or to select available resources based on runtime options. This chapter describes the resource management changes that need to be incorporated into your applications when migrating from Crypto-C ME 3.x.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Default Resource Lists Crypto-C ME 4.1.4 uses a provider model and unified resource management making it possible to use resources from any provider just by linking the application against an additional library. The result of this is that in Crypto-C ME 4.1.4 each provider defines a default resource list for the functionality it provides.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Providers In Crypto-C ME 4.1.4 resources can be added to the library context in three ways: • When created as an array of resources, as in Crypto-C ME 3.x. • After creation as a single resource, or array of resources. • After creation from a provider. In Crypto-C ME 4.1.4, unlike 3.x, resources can be added to the library context multiple times, in each of the different ways, and they are all available for use.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Common Resources Resources that provide core Crypto-C ME functionality, required to use resources from any of the providers, are available from the ccme_core library file. These common resources can be accessed individually for custom resource lists, or as a list using R_PROV_SOFTWARE_get_default_resource_list().
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide ret = R_LIB_CTX_new_ef(list, NULL, &lib_ctx); if (R_ERROR_NONE != ret) goto end; /* Perform Cryptographic operations */ end: } R_LIB_CTX_free(lib_ctx); R_STATE_cleanup(); return 0; The following code examples show setting up a custom resource list for Crypto-C ME 3.x and Crypto-C ME 4.1.4. Custom Resource List - Crypto-C ME 3.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide end: } R_LIB_CTX_free(lib_ctx); R_STATE_cleanup(); return 0; FIPS 140-2 Provider The FIPS 140-2 provider manages the configuration, loading, and unloading of the FIPS 140-2 dynamic libraries. This provider is available when linking against the ccme_fipsprov library. Configuration and loading of FIPS 140-2 libraries is no longer performed automatically. Instead, applications must explicitly create and configure a FIPS 140-2 provider.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide /* Causes the FIPS 140-2 libraries to be loaded from the * R_SHLIB_LD_LIBRARY_PATH environment variable */ ret = R_LIB_CTX_new(list, R_RES_FLAG_DEFAULT, &lib_ctx); if (R_ERROR_NONE != ret) goto end; /* Cryptographic operations */ end: } R_LIB_CTX_free(lib_ctx); return 0; FIPS 140-2 Application - Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide ret = R_LIB_CTX_add_provider(lib_ctx, fips); if (R_ERROR_NONE != ret) goto end; /* Perform cryptographic operations */ end: } R_PROV_free(fips); R_LIB_CTX_free(lib_ctx); R_STATE_cleanup(); return 0; The following table lists the entities for setting equivalent FIPS 140-2 modes for Crypto-C ME 3.x and Crypto-C ME 4.1.4. Table 5 FIPS 140-2 Modes Crypto-C ME 3.x Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide The next step is to load the PKCS #11 driver shared library so that the PKCS #11 provider can access its functionality and configure the hardware devices. In previous releases of Crypto-C ME, this was done using an environment variable that was then parsed by the Crypto-C ME library. In Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide PKCS #11 - Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Loading a PKCS #11 provider queries the PKCS #11 driver library file to determine the slots and tokens available on the device. This can also be done manually by calling R_PROV_PKCS11_update_full() on the R_PROV provider object. Any newly-discovered slots and tokens are added to the provider list, and ones no longer present are removed. PKCS #11 Sample Programs In Crypto-C ME 3.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Table 6 PKCS #11 Function Mapping (continued) Crypto-C ME 3.x Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Table 6 PKCS #11 Function Mapping (continued) Crypto-C ME 3.x Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Environment Variable With Crypto-C ME 4.1.4 use of the RSA_CRYPTOCME_HDW_DLL environment variable is deprecated and it is strongly recommended to store the PKCS #11 driver location and any other information in an external source, such as a configuration file or registry variable, and pass the information into Crypto-C ME. However, applications can continue using the environment variable by adding a feature to the PKCS #11 provider.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Environment Variable - Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Custom Resource Lists Unlike Crypto-C ME 3.x where cryptographic algorithms were a different type of resource found in a sub-list, with Crypto-C ME 4.1.4 all resources are treated the same. One custom list can be used to hold all required resources, or multiple custom lists can be added to the library context separately if you want to categorize resources. The following table lists the resources changed between Crypto-C ME 3.x and Crypto-C ME 4.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide For Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide int main(int argc, char **argv) { int ret; R_LIB_CTX *lib_ctx = NULL; R_RES_LIST *list = app_get_custom_resource_list(); ret = R_LIB_CTX_new(list, 0, &lib_ctx); if (R_ERROR_NONE != ret) goto end; /* Perform cryptographic operations */ end: } R_LIB_CTX_free(lib_ctx); return 0; Custom Resource List - Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Tracing Although not necessary for migration of custom resource lists, Crypto-C ME 4.1.4 provides a tracing API to supply runtime information about the internal operation of the library. Support for tracing is added to the resource selection logic and can be used to observe what resources are being used by the library. The following example code shows how tracing for resource selection can be implemented. #include "bsafe/r_select_r.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide For each resource lookup performed, output like the following is displayed. Search : mod_id(600), res_id(1000000), sub_id(0x000000000) Found (1) resources Filter Ri_RES_FILTER_state matches(1) resources Filter Ri_RES_FILTER_subid matches(1) resources Filter Ri_RES_FILTER_data matches(1) resources The Search line shows which resource is being requested and displays the following information: • mod_id is the module identifier for the resource.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.
Migration Guide 4 Hardware Support This chapter describes the changes in hardware support if you are migrating from Crypto-C ME 3.x. For information about the PKCS #11 provider, see PKCS #11 Provider.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide New Cryptographic Algorithms The following algorithms are now supported on specific hardware devices: • Elliptic Curve DSA (ECDSA) • EC Diffie-Hellman (ECDH) • RSA PSS • HMAC SHA-2. For elliptic curve operations, the full list of NIST-recommended named elliptic curves supported by Crypto-C ME, is supported on specific PKCS #11 hardware devices for specific operations.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide 3. Attach the tracing callback function to the PKCS #11 provider object. For example, static const R_TRACER tracer = { R_TRACE_VERSION_1, R_TRACE_LVL_ALL|R_TRACE_F_DATA, do_trace, NULL }; ret = R_PROV_PKCS11_set_info(p, R_PROV_INFO_ID_TRACER, (void *)&tracer); For more information about tracing in Crypto-C ME, see Tracing in the RSA BSAFE Crypto-C Micro Edition Developers Guide.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.
Migration Guide 5 Cryptographic API Changes This chapter describes the cryptographic API changes you will need to incorporate into your applications when migrating from Crypto-C ME 3.x.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Pseudo-random Number Generation Cryptographic objects, R_CR, implementing a pseudo-random number generator (PRNG) now require initialization, the same as for other cryptographic objects. This change was introduced to allow more advanced configuration of cryptographic objects, such as requesting that an implementation come from a specific provider.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Implementing a PRNG - Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Symmetric Key Encryption Cryptographic Objects Creation of cryptographic objects for symmetric key encryption now expects one or both of the R_CR_SUB_DECRYPT and R_CR_SUB_ENCRYPT sub-identifiers to be specified explicitly to identify the type of operations to be performed. During creation of the cryptographic object, all requested operations are checked for availability in the resource list.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Creating a Symmetric Key Object - Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Example IV Generation Resource List for Crypto-C ME 4.0 through 4.1.3 R_RES_ITEM list[] = { … R_CR_IV_GEN, R_CR_DIGEST_SHA256, … }; Example IV Generation Resource List for Crypto-C ME 4.1.4 - Normal Use R_RES_ITEM list[] = { … R_CR_IV_GEN, R_CR_RANDOM_GENERATOR, … }; Example IV Generation Resource List for Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide The limits of allowed data unit lengths are 16 bytes up to 224 bytes. These limits comply with the requirements of NIST SP 800-38E. Legacy implementations enforced only a lower limit of 16 bytes. The information identifier, R_CR_INFO_ID_XTS_SINGLE_UNIT, used with R_CR_set_info(), maintains compatibility with the way data unit lengths were determined by legacy implementations.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Asymmetric Key Operations Cryptographic Objects Creation of cryptographic objects for asymmetric key encryption now expects one of four sub-identifiers to be specified to identify the type of operations to be performed. In Crypto-C ME 3.x, the sub-identifier was made up of the options R_CR_SUB_PUBLIC, R_CR_SUB_PRIVATE, R_CR_SUB_ENCRYPT, and R_CR_SUB_DECRYPT, which caused confusion and ambiguity in some situations.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide DSA Key and Key Parameter Generation With the release of Crypto-C ME 4.1.4, some of the information identifiers for FIPS 186-2 and FIPS 186-3 DSA key parameter generation are changed. FIPS 186-2 DSA The following table lists details about the FIPS 186-2 DSA key parameter generation information identifiers for Crypto-C ME 4.1.4. Table 10 FIPS 186-2 DSA Key Parameter Generation Information Identifiers Prior to Crypto-C ME 4.1.4 Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide FIPS 186-3 DSA The following table lists details about the FIPS 186-3 DSA key parameter generation information identifiers for Crypto-C ME 4.1.4. Table 11 FIPS 186-3 DSA Key Parameter Generation Information Identifiers Prior to Crypto-C ME 4.1.4 Crypto-C ME 4.1.
Migration Guide 6 Changes Between Releases 4.1.2 and 4.1.4 Crypto-C ME 4.1.4 includes changes made after release Crypto-C ME 4.1.2 that must be considered.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide FIPS 140-2 Mode is the Default Mode Prior to the release of Crypto-C ME 4.1.4, a library context did not have a default mode filter. As a result, any resources managed by a library context were accessible by default. The Crypto-C ME FIPS 140-2 provider includes both FIPS and non-FIPS resources, so both FIPS and non-FIPS resources were available if the FIPS provider was added to a library context. With the release of Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Cryptographic Strength Enforcement By default, Crypto-C ME 4.1.4 requires cryptographic keys for all asymmetric operations to be of sufficient strength. If an operation is attempted with a key that is not strong enough, the operation will fail with an error code of R_ERROR_BAD_STRENGTH. Cryptographic strength is an abstract measure of the security provided by particular cryptographic keys and algorithms when used to protect data.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Note: Although the Crypto-C ME security strength checks can be disabled by setting the minimum strength settings to zero, the protection strength check should never be disabled in a production environment as it allows the library to use weak asymmetric keys that provide no protection whatsoever. Rather than disabling the check, the weak key should be removed from the deployment and replaced by a strong key.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Asymmetric Key Assurance The proper management and use of cryptographic keys is essential to the use of cryptography for security. NIST provides a wealth of guidance for the management of keys, and this is included in the FIPS 140-2 standard. Even when FIPS 140-2 compliance is not required for an application, following the NIST guidance is recommended.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide DSA Key and Key Parameter Generation With the release of Crypto-C ME 4.1.4, some of the information identifiers for FIPS 186-2 and FIPS 186-3 DSA key parameter generation are changed. FIPS 186-2 DSA The following table lists details about the FIPS 186-2 DSA key parameter generation information identifiers for Crypto-C ME: Table 12 FIPS 186-2 DSA Key Parameter Generation Information Identifiers Prior to Crypto-C ME 4.1.4 Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide FIPS 186-3 DSA The following table lists details about the FIPS 186-3 DSA key parameter generation information identifiers for Crypto-C ME: Table 13 FIPS 186-3 DSA Key Parameter Generation Information Identifiers Prior to Crypto-C ME 4.1.4 Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Diffie-Hellman Operations With the release of Crypto-C ME 4.1.4, the underlying specifications for performing Diffie-Hellman (DH) key exchange, key generation, and key parameter generation are changed. Prior to Crypto-C ME 4.1.4, DH key exchange and generation, and key parameter generation was performed according to the specifications outlined in IEEE P1363 draft 10 Section A.16.1. From Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide The following table lists the DH key exchange information identifiers for Crypto-C ME: Table 15 Diffie-Hellman Key and Key Parameter Generation Information Identifiers Prior to Crypto-C ME 4.1.4 Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide The following table lists details about the DH key and key parameter generation information identifiers for Crypto-C ME 4.1.4. Table 17 Diffie-Hellman Key and Key Parameter Generation Information Identifiers Prior to Crypto-C ME 4.1.4 Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Pre-defined Diffie-Hellman Parameters Crypto-C ME 4.1.4 includes built-in DH parameter values, also known as safe primes, from well-known DH groups. The values for these parameters are published in the following documents: • RFC 7919 • RFC 3526 • RFC 7296 These parameters have been validated and should be used in preference to newly generated parameters to promote security, interoperability and efficiency.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Key Wrapping Key wrapping is a method of encrypting key data for protection on untrusted storage devices or during transmission over insecure channels. In previous versions of Crypto-C ME, wrapping of key data was provided using specific key wrap algorithms, using AES symmetric key encryption, or applications could use asymmetric key encryption and wrap key data using a recipient’s public key.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide The following table lists the algorithm subtypes to specify when creating a cryptographic object for key wrapping ind Crypto-C ME 4.1.4. Table 19 Key Wrapping Algorithm Subtypes Crypto-C ME 3.1 through 4.1.3 Crypto-C ME 4.1.4 R_CR_SUB_NONE If wrapping with a symmetric key, R_CR_SUB_SYMMETRIC_KEY, plus the type of key you are wrapping. One of: • R_CR_SUB_WRAP_SKEY • R_CR_SUB_WRAP_PKEY • R_CR_SUB_WRAP_RAW.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Wrap the Key Data The following table lists the functions used to wrap the key data in Crypto-C ME 4.1.4. Table 21 Key Wrapping Functions Crypto-C ME 3.1 through 4.1.3 Crypto-C ME 4.1.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Initialization Vector Generation Initialization Vector (IV) generation for symmetric key encryption is updated for compliance with the latest FIPS 140-2 implementation guidance (IG A.5). Crypto-C ME 3.x did not support IV generation. In Crypto-C ME releases 4.0 to 4.1.3, IV generation was deterministic, using a message digest implementation to compress the input values used for IV generation.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Elliptic Curve Private Key Format Crypto-C ME 4.1 introduced new write formats for elliptic curve (EC) private keys for the following functions: • R_PKEY_to_binary() • R_PKEY_to_bio() • R_PKEY_to_file() R_PKEY_to_binary() now writes in the format described in RFC 5915. To write EC private keys in the pre-4.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide Namespace Changes Crypto-C ME 4.1.4 introduces namespace changes to achieve greater consistency with the rest of the source code. Specifically, the bio.h header file is renamed as r_bio.h. Migrate your applications to use the R_BIO_*() set of functions. For now, the BIO_*() functions are deprecated.
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide 70 Chapter 6: Changes Between Releases 4.1.2 and 4.1.
