TAP APIs

The NanoTAP API Reference provides information about the vendor and platform agnostic APIs exposed to applications. Unless otherwise specified, all functions return MSTATUS. Each TAP API has a TAP_ErrorContext as the final argument. This argument is populated only in debug mode; in production builds, the caller may simply pass in NULL.

Plugin developers are responsible for providing the APIs to handle internal structures, such as keys and objects. Each SMP must also provide a dispatcher function.

TAPS dispatcher

The TAPS dispatcher parses the command from the client. It performs any translations needed between TAP and SMP types and structures, and then sends the command on to the SMP dispatcher. The SMP dispatcher is responsible for verifying all module-specific information and handling all supported commands. It must return TAP_ERR_CMD_NOT_SUPPORTED for unsupported command codes. The module must perform checks on argument validity and must not rely on TAP having validated the arguments.

TAP serialization helper library

The TAP serialization helper library can be used for easily converting APIs to remote procedure calls (RPCs). The TAP communication library code adds a TAP header and sends the serialized command to the server. Once the server receives the response, the TAP server strips the TAP header and sends the command to the module-specific dispatcher for processing. The plugin developer must provide the dispatcher function and any additional command handler functions required. Upon completion of the command, the TAP server adds a TAP header to the response and returns it to the caller.

Client-server model

In the client-server model, all TAP client requests are sent to the TAP server, regardless of whether the security module host is local or remote. Therefore, the TAP server must be running for commands to succeed. The administrative set of NanoTAP command line tools that can only be executed locally are exceptions to this rule. These are compiled without the client-server code and call directly into the module-specific code. Therefore, the server does not need to be running to execute this set of tools. Similar tools may be available for any SMP and the user should refer to the documentation for the specific SMP.

Managing memory

Some APIs return buffers that have been allocated and must be freed using MOC_FREE. Typically, these APIs return a TAP_Buffer * value, in which the pBuffer field must be freed. APIs that support module-specific values do so using the TAP_Attribute and TAP_AttributeList structures. Refer to the description of each API for further details in the NanoTAP API Reference.

TAP key API usage

NanoTAP has its own key structure, TAP_Key, which contains information that determines the key and provider type. The TAP_Key structure is used within the TrustCore SDK MocAsymKey and MocSymKey types for compatibility with NanoCrypto. NanoTAP keys can then be used in calls made directly to NanoTAP APIs or through Crypto Interface APIs.