FAQs
This section provides solutions to common questions considered during NanoSSH Client customization and integration efforts.
TrustCore SDK NanoSSH supports certificate-based authentication (RFC 6187), public-key authentication, and password client authentication. Typically, the product’s market determines the appropriate authentication method. Datacom applications usually use password authentication, while federal projects typically require certificates and keys.
If there is still a choice, we recommend using the most secure authentication method supported by the target market. That is, use certificate-based authentication if possible. Public key authentication is still preferred over password-based authentication is even if both keys and passwords are transmitted over a secure channel.
The default method of building the NanoSSH application from the TrustCore SDK source code does not result in a FIPS-certified application. However, after completing application integration and testing, it may be integrated with a licensed TrustCore SDK NanoCrypto FIPS binary, which allows FIPS 140-2 certification to be claimed for the application.
For more information, see FIPS and Suite B Support, and Adding FIPS.
TrustCore SDK components use callback functions during authentication to verify public keys, which are managed as byte string representations of TrustCore SDK formatted for version 1 or version 2 key BLOBs.
Version 1 Key BLOBS
Key BLOBs for version 1 are formatted as follows:
Key BLOBs begin with a 12-byte header, with all bytes set to zero except the following:
header[7] contains the TrustCore SDK key BLOB version (1)
header[11] contains the key type (akt_* enumerated values defined in ca_mgmt.h)
For DSA keys, the data following the header is:
4 bytes length of p string
n bytes length of p byte string
4 bytes length of q string
n bytes length of q byte string
4 bytes length of g string
n bytes length of g byte string
4 bytes length of y string
n bytes length of y byte string
4 bytes length of x string
n bytes length of x byte string
For RSA keys, the data following the header is:
4 bytes length of e string
n bytes length of e byte string
4 bytes length of n string
n bytes length of n byte string
4 bytes length of p string
n bytes length of p byte string
4 bytes length of q string
n bytes length of q byte string
4 bytes length of private string #1
n bytes length of private byte string #1
4 bytes length of private string #2
n bytes length of private byte string #2
4 bytes length of private string #3
n bytes length of private byte string #3
4 bytes length of private string #4
n bytes length of private byte string #4
4 bytes length of private string #5
n bytes length of private byte string #5
For ECC keys, the data following the header is:
1 byte OID suffix identifying the curve
4 bytes length of Point string
n bytes length of Point byte string (uncompressed X9-62 format)
4 bytes length of Scalar string
n bytes length of Scalar byte string
Key BLOBs for version 2 are formatted as follows: - 4 bytes: all zeros - 4 bytes: version number which must be 0x00000002 - 4 bytes: key type which must be one of the KEYBLOB_TYPE enums - 4 bytes: OID type which must be one of the MAlgoOid enums - N bytes: ASN.1 encoded algorithm identifier - 4 bytes: reserved - N bytes: reserved - 4 bytes: key data length (keyblen) - Keylen bytes: key data (key data formats are mentioned above)
To build a library using a cmake project, use the following scripts in the scripts/nanossh/ssh_client directory to build libraries for ssh_server. These scripts along with the CMAKE projects are provided as part of the sources and are configured to build binaries with specific features. If required, to enable or disable a feature, make the necessary extensions to build and include their flags.
For Export edition builds,
--mbed-pathmust be provided as an option with a path to the MbedTLS libraries.
Binaries Support SW private keys only:
US Edition –
build_ssh_server_ncrypto.shExport Edition –
build_ssh_server_export.sh
Superset binaries with SW and TAP (Secure Element) Private Keys Support (Local TAP library mode)
US Edition –
build_ssh_server_tap_local_ncrypto.shExport Edition –
build_ssh_server_tap_local_export.sh
Superset binaries with SW and TAP (Secure Element) Private Keys Support (TAP Server remote mode)
US Edition –
build_ssh_server_tap_remote_ncrypto.shExport Edition –
build_ssh_server_tap_remote_export.sh
Binaries Support SW private keys only:
US Edition –
build_ssh_client_ncrypto.shExport Edition –
build_ssh_client_export.sh
Superset binaries with SW and TAP (Secure Element) private keys support (local TAP library mode)
US Edition –
build_ssh_client_tap_local_ncrypto.shExport Edition –
build_ssh_client_tap_local_export.sh
Superset binaries with SW and TAP (secure element) private keys support (TAP server remote mode)
US Edition –
build_ssh_client_tap_remote_ncrypto.shExport Edition –
build_ssh_client_tap_remote_export.sh
This shared object is required to use hybrid algorithms.
To build an Open Quantum Safe library:
Open a terminal and verify that all required prerequisites have been met by running the following commands:
which ninjacmake –version
Change the to the liboqs library.
cd <path to liboqs>
Generate the NanoSSH build.
mkdir build && cd build
Run cmake to build the library.
cmake -GNinja .. -DOQS_USE_OPENSSL=OFF -DBUILD_SHARED_LIBS=ON
Run ninja.
ninja
When using Export Edition scripts, provide the path to the directory containing the shared object.
To build the NanoSSH export edition for a third-party library:
Open a terminal and verify that all required prerequisites have been met by running the following command:
cmake –version
Change to the mbedtls directory.
cd <path to mbedtls>
Generate the NanoSSH build.
mkdir build && cd build
Run cmake to create the library.
cmake -DUSE_SHARED_MBEDTLS_LIBRARY=On ..
Run make.
make
Optionally, run make test.
make test