InfiniShield Security¶

The InfiniShield Security software framework provides built-in access to robust device authentication and secure connections, secure protection for keys, configuration and firmware, and centrally managed identity and access control. A manufacturer can build InfiniShield Security features into their connected products from the start of the design cycle.

InfiniShield Security includes the following features:

• PKI and Certificate Management
• Enterprise Wi-Fi Security
• Secure Boot
• Secure Firmware Over the Air (FOTA)
• Encrypted Key and Configuration Store
• Data Communication Security (TLS)
• Network Service Policy Control

PKI and Certificate Management¶

Public key infrastructure (PKI) is based on an encryption technique that uses two keys: a public key and a private key. Public keys can be used to encrypt messages that can only be decrypted using the private key. This technique is referred to as asymmetric encryption, as opposed to symmetric encryption, in which a single secret key is used by both parties.

Digital Certificates¶

The goal of a digital certificate is to authenticate its sender. It is analogous to a paper document that contains personal identification information and is signed by an authority, for example a notary or government agency. With digital certificates, a cryptographic key is used to create a unique digital signature. A digital certificate is valid for specified period of time.

Trusted Authorities¶

A chain of signed certificates, anchored by a root CA, can be used to establish a sender's authenticity. Each link in the chain is certified by a signed certificate from the previous link, with the exception of the root CA. This way, trust is transferred along the chain, from the root CA through any number of intermediate authorities, ultimately to the agent that needs to prove its authenticity.

Obtaining Certificates¶

Signed certificates are typically obtained from well-known CAs, such as Verisign, Inc. This is done by submitting a certificate request for a CA, typically for a fee. The CA will sign the certificate request, producing a certificate/key combo: the certificate contains the identity of the owner and the public key, and the private key is available separately for use by the owner.

As an alternative to acquiring a signed certificate from a CA, you can act as your own CA and create self-signed certificates. This is often done for testing scenarios, and sometimes for closed environments where the expense of a CA-signed root certificate is not necessary.

Certificate Format¶

Certificates and private keys can be stored in several file formats, including PKCS12, DER and PEM. The certificate and key can be in the same file or in separate files. Additionally, the key can either be encrypted with a password or left in the clear. The xPico 200 series gateway only accepts separate PEM files, with the key unencrypted. Several utilities exist to convert between the formats. Keys in other formats will need to be converted before being used with the xPico 200 series.

For information on how to configure a TLS credential, see Creating a TLS Credential.

Enterprise Wi-Fi Security¶

Enterprise Wi-Fi security (WPA2-Enterprise) uses existing IT infrastructure such as RADIUS and LDAP/Active Directory servers for centralized control and policy management, PKI and X.509 certificates for strong security with mutual authentication, remote provisioning, and a common set of standard protocols to manage access and connectivity of Wi-Fi devices to the rest of the Enterprise network.

For information on configuring Wi-Fi security for xPico 200 series gateways, see WLAN Network Profiles.

Secure Boot¶

The Secure Boot component ensures that only authorized software is allowed to run on the gateway and is enabled by default. Secure Boot prevents the execution of unauthenticated code. Only firmware images signed by Lantronix or from an authorized OEM that has personalized the gateway's one-time programmable (OTP) memory can be loaded to the gateway.

For additional security and to prevent writes into the OTP area while using Lantronix signed firmware, enable the Secure Bit at manufacturing using the Manufacturing Test Loader.

An OEM who wants to build their own firmware needs to obtain an authorization key from Lantronix and program it into the gateway during the manufacturing of their product. Once that is done, only firmware images signed by the OEM can be loaded. For more information on the firmware signing process and loading your own custom firmware, refer to the xPico 200 series SDK User Guide.

For more information on keeping your device secure, see Securing Your Device.

Enable Secure Bit¶

Follow these steps to enable Secure Bit and ensure only authorized firmware is loaded to your gateway.

1. Connect to the device with a terminal emulator such as Tera Term.
2. Configure the serial port. In Tera Term, click Setup and then Serial port....
   • Set Port to the port you are using to connect to the device.
   • Set Baud rate to 8 bit.
   • Set Parity to none.
   • Set Stop to 1 bit.
   • Set Transmit delay to 0 msec/char and 0 msec/line.
   • Set Flow Control to hardware.
   • Click OK.
3. Save the Manufacturing Test Loader macro to your PC and run it using Tera Term. In Tera Term, click Control and then Macro. Select the macro and click Open.
4. Select the Manufacturing Test Loader .rom file and click Open.
5. Follow the prompts provided by Tera Term to send Manufacturing Test Loader to the device.
6. In the CLI, type otp writesecurebit confirm.

Secure Firmware Over the Air (FOTA)¶

xPico 200 series gateway support over-the-air firmware updates. A dual boot bank methodology is adopted within the gateway to ensure the firmware-over-the-air (FOTA) update does not render the unit unusable.

With built-in support for Secure Boot, the firmware-over-the-air (FOTA) process only accepts signed firmware that is authorized to be flashed into the gateway. The signed firmware image is authenticated by the secure bootstrap before it is flashed on the unit.

For information on how to perform a firmware upgrade, see Secure Firmware Over the Air (FOTA) Update

Encrypted Key and Configuration Store¶

User configuration data and internal device data are stored in the file system, which resides in flash separate from the processor chip. Configuration items that are designated as "secret" data are stored encrypted to secure the data.

Data Communication Security (TLS)¶

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), use asymmetric encryption for authentication. In some scenarios, only a server needs to be authenticated, in others both client and server authenticate each other. Once authentication is established, clients and servers use asymmetric encryption to exchange a secret key. Communication then proceeds with symmetric encryption, using this key.

TLS/SSL application hosts use separate digital certificates as a basis for authentication in both directions: to prove their own identity to the other party, and to verify the identity of the other party. In proving its own authenticity, the xPico 200 series gateway will use its own "personal" certificate. In verifying the authenticity of the other party, the xPico module will use a "trusted authority" certificate.

On the gateway, you use a TLS Credential to configure the TLS properties between two communicating applications.

Creating a TLS Credential¶

The TLS Credential contains the private key and certificate details. You can use TLS for TCP and UDP connections as well as for secure HTTP Server.

Creating a TLS Credential is a two-step process.

STEP 1: Create a new TLS Credential

1. Create and name the credential. The new credential initially has empty certificate and private key values.

STEP 2: Configure the TLS Credential

1. Configure which TLS protocol versions the credential supports.
2. Copy and paste the private key into the credential.
3. Copy and paste the certificate into the credential.
4. Configure the Higher Authority and Trusted Authority instances, if necessary.

You can delete the TLS credential, which will delete the credential from any associated connections.

To configure TLS Credentials:

In Web Manager, go to TLS Credentials.

For the CLI, see Config TLS Credential level.

For XML, see Configgroup TLS Credential.

Creating an AES Credential¶

The AES Credential is used with TCP connections requiring AES.

The AES Credential contains an Encrypt Key and Decrypt Key for encrypting outgoing data and decrypting incoming data. These keys are a shared secret, so both sides of the connection must be knowledgeable of them and kept secret. The keys can be 16, 24 or 32 bytes in length.

Example Hexadecimal Key: 12 34 56 78 9a bc de f0 01 02 03 04 05 06 07 08.

Creating an AES Credential is a two-step process.

STEP 1: Create a new AES Credential

1. Create and name the credential. The new credential initially has empty Encrypt and Decrypt Key values.

STEP 2: Configure the AES Credential

1. Copy and paste the Encrypt Key for encrypting outgoing data.
2. Copy and paste the Decrypt Key for decrypting incoming data.

To remove the key, set the field to a blank value.

You can delete the AES credential, and the change will take effect immediately.

To configure AES Credentials:

In Web Manager, go to AES Credentials.

For the CLI, see Config AES Credential level.

For XML, see Configgroup AES Credential.

Network Service Policy Control¶

The gateway provides policy based access control to network services and input/output ports.

You have a number of different control options. You can:

• Enable or disable network services and interfaces in the configuration settings.
• Configure the network ports for client and server connections in the configuration settings.
• Configure HTTP Server Security policies to manage access to target URIs based on the user role. See HTTP(S) Server.
• Customize the Web UI to hide (or display) modules according to your product's capabilities. See OEM Branding and Customization.