2-DIMENSIONAL IOT SECURITY AND MANAGEMENT (BY OTHERS)
The Building Blocks of TrustCentral’s 3-Dimensional IoT solution start by building upon a foundation of existing trusted technologies provided by others (the 2-Dimensional IoT technologies described here). It is referred to as “2-Dimensional” because it generally supports IoT authentication, security and management from a-central-point-to-an-endpoint (e.g., the traditional application of Public Key Infrastructure – PKI). Its elements are generally well known. Many are becoming better known and utilized broadly in IoT management and security. Each is valuable (if not vital). TrustCentral leverages these technologies in order to support the innovative and proprietary building blocks of its Trust Stack.
- Each is a vital component of IoT security
- Each views IoT devices on an individual basis
- These technologies are currently available in high quality
Examples include: AWS Greengrass (providing some of the below described 2-Dimensional IoT elements); and Azure IoT Hub and IoT Sphere (which together provide most of these 2-Dimensional IoT elements);
The key foundation of the Trust Stack is Public Key Infrastructure (PKI). PKI is also the foundation of security for the Internet itself. The Platform will incorporate a complete X.509 PKI and Privilege Management Infrastructure (PMI).
DEVICE ROOT OF TRUST
IoT security begins at the device level with a unique, securely stored or accessible, non-volatile ID or private key in order to provide a secure root of trust. For an IoT device such a root of trust can be achieved the chip level through the use of one or more existing technologies. In one example, a digital “fingerprint” can be created using a small portion of a device’s silicon with the application of PUF (Physically Unclonable Function) technology. The PUF becomes a digital “anchor” to provide vital, security-supporting capabilities. Another method of establishing a root of trust is key injection into the chip during its production process (key injection must be executed with precision using industry standard procedures).
To take full advantage of the Security Ecosystem features, IoT devices are provisioned with crypto capabilities allowing them to perform functions such as encryption and decryption of data, digital signing and other functions. Provisioning should include the installation of public keys to trust (not only for trusted firmware updates but for secured needs such as for an IoT device to allow trusted access by a maintenance group). Crypto implementations must also anticipate future threats from quantum computing to present day crypto algorithms.
(For human-controlled devices such a computers, tables and mobile devices, other technologies can be used to provide a comparable root of trust.)
DEVICE IDENTITY CERTIFICATION
The system provides for the authentication of a cryptographically-secure, non-repudiable identity tied directly to each IoT end-point. For example, an identity may be as a particular vehicle ECU (Electronic Control Unit), sensor, etc. Validation of that identity is confirmed by the issuance of a PKI certificate. (Note that the Security Ecosystem can manage the process of authenticating identities and issuing these certificates.)
SECURITY BEST PRACTICES
The TrustCentral solution implementation includes the adoption of industry best practices. One of the most important best practices secure boot. Another is secure, signed firmware updating and management. Every IoT device within a vehicle (or devices within external infrastructure that a vehicle might interface with, etc.) should be updatable with authenticated, signed firmware. There are a variety of standards that can be used to accomplish this including Over the Air (OTA) . Further, firmware updates may be executed on different firmware types (e.g., boot images, higher-level embedded code, underlying software components) as well as being accomplished in chunks in order to minimize device power consumption.
ANOMALY DETECTION, FAILURE REPORTING
Anomaly detection of IoT events or observations that do not conform to expected patterns is highly recommended. Alsosoftware failures (such as a buffer overrun induced by an attacker probing security) need to be reported to central failure analysis system.