Skip to main content

FAQs

This section provides solutions to common questions considered during NanoSSH server customization and integration efforts.

DSA, RSA, or ECDSA Encryption?

TrustCore SDK NanoSSH supports DSA, RSA, and ECDSA encryption for host authentication, all of which are allowed in FIPS-compliant implementations. So which one should be used? It depends, and the tradeoffs must be made based on system requirements:

  • Strength: If security is the most important factor, the best choice is ECDSA, followed by RSA, and then DSA.

  • Interoperability: If interoperability is the most important factor, the best choice is DSA, followed by RSA, and then ECDSA. That is, the ordering for interoperability is the opposite of the ordering for strength. For maximum interoperability, all of the encryption methods may be enabled.

  • Speed: RSA is significantly faster than DSA, typically by a factor of three (3).

  • Key size: ECDSA uses smaller keys than comparably secure DSA implementations, so if key size is a consideration, use ECDSA.

In all cases, DSA is the least desirable and should not be used unless it is the only option.

Per the SSH protocol definition, RSA support is optional; therefore, some clients require DSA to be used.

After deciding which encryption methods to enable, define the appropriate compilation flags before building the code. Refer to the Building TrustCore SDK Components guide.

Public-Key or Password Authentication?

TrustCore SDK NanoSSH supports both public-key and password client authentication. Typically, your 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, TrustCore SDK recommends using public keys even though both keys and passwords are transmitted over a secure channel.

How Do I Enable a Given Cipher Suite?

When negotiating connections, NanoSSH server may use the strongest cipher suite available, or the desired cipher settings may be specified. Table 7 below lists the available ciphers and the TrustCore SDK compilation flag definition required to enable the cipher.

NanoSSH Cipher Suites

  • AES (256-bit) Ciphers

    • Ciphers: aes256-ctr, aes256-cbc, rijndael256-cbc

    • Flags:

      • Undefine: __DISABLE_AES_CIPHERS__, __DISABLE_AES256_CIPHER__

  • AES-GCM (256-bit) Ciphers

    • Ciphers: AEAD_AES_256_GCM, aes256-gcm@openssh.com

    • Flags:

      • Undefine: __DISABLE_AES_CIPHERS__, __DISABLE_AES256_CIPHER__

      • Define: __ENABLE_MOCANA_GCM__ (for AES-GCM only)

  • AES (192-bit) Ciphers

    • Ciphers: aes192-ctr, aes192-cbc, rijndael192-cbc

    • Flags:

      • Undefine: __DISABLE_AES_CIPHERS__, __DISABLE_AES192_CIPHER__

  • AES (128-bit) Ciphers

    • Ciphers: aes128-ctr, aes128-cbc, rijndael128-cbc

    • Flags:

      • Undefine: __DISABLE_AES_CIPHERS__, __DISABLE_AES128_CIPHER__

  • AES-GCM (128-bit) Ciphers

    • Ciphers: AEAD_AES_128_GCM, aes128-gcm@openssh.com

    • Flags:

      • Undefine: __DISABLE_AES_CIPHERS__, __DISABLE_AES128_CIPHER__

      • Define: __ENABLE_MOCANA_GCM__ (for AES-GCM only)

  • Blowfish Cipher

    • Cipher: blowfish-cbc

    • Flag: Define __ENABLE_BLOWFISH_CIPHERS__

  • 3DES Cipher

    • Cipher: 3des-cbc

    • Flag: Undefine __DISABLE_3DES_CIPHERS__

  • ChaCha20-Poly1305 Cipher

    • Cipher: chacha20-poly1305@openssh.com

    • Flags:

      • Define: __ENABLE_MOCANA_CHACHA20__, __ENABLE_MOCANA_POLY1305__

  • ECC P521 Ciphers

    • Ciphers: ecdh-sha2-nistp521, ecdsa-sha2-nistp521, x509v3-ecdsa-sha2-nistp521, x509v3-ecdsa-sha512-nistp521

    • Flags:

      • Define: __ENABLE_MOCANA_ECC__

      • Undefine: __DISABLE_MOCANA_ECC_P521__

  • ECC P384 Ciphers

    • Ciphers: ecdh-sha2-nistp384, ecdsa-sha2-nistp384, x509v3-ecdsa-sha2-nistp384, x509v3-ecdsa-sha384-nistp384

    • Flags:

      • Define: __ENABLE_MOCANA_ECC__

      • Undefine: __DISABLE_MOCANA_ECC_P384__

  • ECC P256 Ciphers

    • Ciphers: ecdh-sha2-nistp256, ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-nistp256, x509v3-ecdsa-sha256-nistp256

    • Flags:

      • Define: __ENABLE_MOCANA_ECC__

      • Undefine: __DISABLE_MOCANA_ECC_P256__

  • ED25519 Cipher

    • Cipher: ssh-ed25519

    • Flags:

      • Define: __ENABLE_MOCANA_ECC, __ENABLE_MOCANA_ECC_EDDSA_25519__

How are Key BLOBs Formatted?

TrustCore SDK components use callback functions during authentication to verify public keys, which are managed as byte string representations of TrustCore SDK code 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

Version 2 Key BLOBS

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)

What Are the TrustCore SDK Common Initialization Steps?

Applications should perform the TrustCore SDK initialization and shutdown work, as shown in the src/examples/mocana_example.c sample module. In particular, make the following function calls and perform the following procedures:

  • MOCANA_initMocana — Initialize the TrustCore SDK code base (logging, random number generator, and so on).

  • MOCANA_initLog — Optionally, register a callback function to the TrustCore SDK logging system.

  • Create threads for all required TrustCore SDK component servers (e.g., the NanoSec IKE server).

  • Implement a status-checking loop that runs and sleeps as long as an application running flag is true.

  • MOCANA_freeMocana — Release memory that was allocated by MOCANA_initMocana.

Can I Use Port Forwarding?

Yes, NanoSSH supports both single and multiple local port forwarding. This feature enables an application client to make a secure virtual connection to application servers via NanoSSH Server and NanoSSH Client. Use the ssh command to set up a virtual connection; then when an application client wants to communicate with an application server, it does so through a secure pipe. Commands may then be executed on the application server.

Syntax

ssh -L<Local Listening Port>:<Remote Host>:<Remote Port> <username>@ssh_server

Note: <Remote Host> and ssh_server may be IP addresses or domain names.

For example, to set up single port forwarding, use the following command:

ssh -L2799:192.168.3.59:2799 root@11.8.12.

How Do I Build Libraries Using a cmake Project?

To build a library using a cmake project, use the following scripts in the scripts/nanossh/ssh_server 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.

Note: For Export edition builds, --mbed-path must be provided as an option with a path to the MbedTLS libraries.

Scripts for ssh_server

  • Binaries Support SW private keys only:

  • US Edition – build_ssh_server_ncrypto.sh

  • Export 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.sh

  • Export 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.sh

  • Export Edition – build_ssh_server_tap_remote_export.sh

Scripts for ssh_client

  • Binaries Support SW private keys only:

  • US Edition – build_ssh_client_ncrypto.sh

  • Export 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.sh

  • Export 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.sh

  • Export Edition – build_ssh_client_tap_remote_export.sh

Build the Export Edition for a third-party library

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:

  1. Open a terminal and verify that all required prerequisites have been met by running the following command:

    cmake –version

  2. Change to the mbedtls directory.

    cd <path to mbedtls>

  3. Generate the NanoSSH build.

    mkdir build && cd build

  4. Run cmake to create the library.

    cmake -DUSE_SHARED_MBEDTLS_LIBRARY=On ..

  5. Run make.

    make

  6. Optionally, run make test.

    make test

Build an open quantum safe library

This shared object is required to use hybrid algorithms.

To build an Open Quantum Safe library:

  1. Open a terminal and verify that all required prerequisites have been met by running the following commands:

    which ninja
cmake –version

  2. Change the to the liboqs library.

    cd <path to liboqs>

  3. Generate the NanoSSH build.

    mkdir build && cd build

  4. Run cmake to build the library.

    cmake -GNinja .. -DOQS_USE_OPENSSL=OFF -DBUILD_SHARED_LIBS=ON

  5. Run ninja.

    ninja
In this section: