Authentication, Authorization, Accounting (“AAA”)
Are a well-accepted family of protocols that mediate traditional network access and are also highly for the IoT
Authentication – who/what can connect or be on a network?
• Process of determining whether a device/endpoint really is who/what it say it is
• TrustCentral does not itself provide Authentication, but does depend upon it
Authorization – what can a connected device do?
• Process of determining what a device can/cannot do relative to data and other devices
• Authorization works hand-in-hand with authentication
• Device privileges (Rules, Business Logic) are delivered/enforced at the device level using certificates
• Certificate-based rules govern device interactions, activities and data handling
• TrustCentral’s proprietary technology excels at IoT Device Authorization
Accounting – what did a device do or provide and when?
• Process of monitoring and recording a device’s activities; its exchanges of data
• TrustCentral’s technology IoT device management is designed with layered auditability measures
• The technology makes extensive use of digital signing
• Provides excellent proprietary support for Accounting of IoT devices and their data
ADDITIONAL DETAIL ON TRUSTCENTRAL TECHNOLOGY AND AAA
DEVELOPING INDUSTRY STANDARDS
Over recent years technology elements (we identify five of them on our Trust Stack, each provided by others) have been being developed/refined to then support the authentication of IoT devices. An ecosystem of interrelated technologies is becoming aligned to achieve this.
BUILT ON PKI (PART OF THE X.509 STANDARD)
These complimentary technologies are being established on a common foundation of Public Key Infrastructure (PKI). Beyond PKI, these integrated foundational elements include a device root of trust, certificate based authentication, security best practices and anomaly detection/failure reporting (as described on our Trust Stack).
Authorization is the process that determines what an authenticated device can and cannot do relative to other devices, endpoints and data. Authorization works hand-in-hand with authentication. TrustCentral’s primary value-added for the support of AAA for the IoT is its proprietary technology for device authorization, privileges, etc. using certificates installed at the device level.
In order to support IoT device authentication (a core proprietary feature) TrustCentral builds upon the authentication elements (described above) by then establishing and then authorizing Secure Communication Lines (i.e., relationships) between endpoints. This is completed by the issuance of a certificate at the device level for each Communication Line.
In general, the basic unit of IoT device communication is a pair: either between two endpoints or between an endpoint and an authorized Group. The actions of IoT devices (particularly their insecure actions) is often centered around their unauthorized or improper communication with malicious endpoints. TrustCentral’s authenticated, Secure Communication Lines enforce authorized device interactions and data handling through the use of attribute certificates.
ATTRIBUTE AUTHORITY, ATTRIBUTE CERTIFICATES
TrustCentral’s innovative IP for IoT is built on the X.509 standard of Public Key Infrastructure (PKI) and Privilege Management Infrastructure (PMI). Communication line paired relationships are authenticated with PMI attribute certificates that also authorize device privileges and rules. TrustCentral’s proprietary use of PKI and PMI provides IoT devices with simple, easy to follow and precise instructions at the device level that are appropriate for such limited-resource devices (for these purposes, it is advantageous that the X.509 standard allows the incorporation of binary and text files within attribute certificates).
TrustCentral’s proprietary Attribute Authority acts as a Trusted Third Party mediating service provider for users/devices and performs many unique functions.
Two of the major roles of the Attribute Authority are:
- Running an Inviter-Invitee Protocol to authenticate communication lines between paired endpoints (which establish and make known the channels on which communication may only flow)
- Generating signed attribute certiﬁcates that are associated with an endpoint identity or with a specific communication line shared by a pair of endpoints. These certificates authenticate and authorize the relationships between endpoints that receive and transmit to and from each other (or with groups) together with associated privileges, rules and authorizations.
Networks may implement the solution by authenticating, pairing and authorizing each device as it goes into service. What could otherwise end up being a complex network of IoT devices, may become instead a network of specifically white-listed device-relationships that is enforced and secured by a combination of PKI and attribute certificates. The result will be an exact, precise, auditable and secure network of IoT devices.
USE CASE EXAMPLE: this technology will not only support IoT device security and management, but also offer DDoS mitigation at the device level.
USE CASE EXAMPLE: a component of vehicle A may be able to distinguish that it is receiving a command or query from a component of vehicle A as opposed to a component of vehicle B, and may be able to ascertain the legitimacy of the command or query as coming from a drive component as opposed to coming from an entertainment system component so that appropriate authorization and/or confidential isolation can be achieved even within the same vehicle.
The system includes capabilities to monitor and record each device’s activity. The system has been designed with layered auditability measures and makes extensive use of digital signing, thus providing support for granular accounting metrics.
In a published paper he wrote for the IEEE, Dr. Kravitz stated this about IoT device data: “Trusted transactions require trusted provenance”. In that paper he makes the case that TrustCentral’s technology can be used to solve the challenge of authenticating and trusting IoT device data (and accounting for it in the process). For more information, see Enhancing Blockchain (which provides immutability but not correctness): “Trusted transactions require trusted provenance”