In the age of the Internet of Things, more and more devices are getting connected; and security is the most critical requirement for connected devices.
We have cryptography stacks and algorithms to protect data transaction between devices but is it enough to secure the whole ecosystem? In one honest word: no.
Security is more than encryption, and therefore each layer from Hardware to Cloud needs to be studied carefully. Herein, we could mention lots of layers in security, but we can basically divide "Security" into two distinct areas: Data Transaction Security and Functional Security.
All we are familiar with Data Transaction Security: encryption, transport and decryption.
However, Functional Security can be a new concept for some of us, but it is as critical as Data Transaction Security while security is only as strong as the weakest link.
Functional Security
Functional Security is securing the device functionality and device resources from external attacks.
Attackers do not only attack encrypted networks, but also attackers attack devices, and this can be physical - even by opening the device case. There are lots of different type of attacks which are out of this paper scope but briefly, side channel attacks or tampering are examples of "Physical Attacks": tamper the device and steal the cryptographic data (e.g. keys) to decrypt sensitive data or networks. As an example of "Logical Attacks", attackers use malfunctioned software in the device to access restricted, sensitive resources.
When an attack happens, the expected behaviour from a Functional Secure system should be “Protecting Itself” because if you cannot protect your sensitive data (e.g. cryptographic keys) in your device, how can you protect your network and data transaction which encrypted by keys in the device? So, it means Functional Security also secures Data Transaction Security.
Security starts with the physical device so Functional Security is the "Root of Trust".
Functional security needs hardware and software level protection. Hardware-level security (e.g. address range check) must be provided by processors itself. On the other hand, IoT Endpoints (e.g. sensors) mostly uses small processes which don’t have advanced security features. In this case, hardware could be upgraded by advanced (but expensive) processors which is not cost effective when we consider millions/billions of devices.
Luckily, there is some significant progress like Arm’s TrustZone® for Cortex-M profile processors. TrustZone® is not a new technology, but it has been using on Application Processors (e.g. Cortex-A profile) which is not suitable for IoT Endpoint (small) devices, but TrustZone® for Cortex M profile microcontrollers like Cortex-M23 and Cortex-M33 will fill the hardware level functional security gap in IoT.
Upgrading all devices in the field with secure hardware components is not easy for an Original Equipment Manufacturer (OEM). It is not time and cost effective. Therefore, software level protections can be a smooth transition for manufacturers. On the other hand, this transition still will be painful because manufacturers could take the responsibility of security and could implement the security features in their custom end-user applications, but painful process here is that all team would have to be expert in security. Moreover, if each product implements its specific security policy, we will never have a universal security policy.
If we are looking for proven universal security policies in software level, we need to solve this problem in software platform level rather than end-user applications, so we need to solve this problem in Operating System Level which can be common for all different type of security-critical devices.
An Operating System is a resource manager, and resources have attributes so if we add a “security” dimension as a new attribute onto operating system resources, we could securely manage operations and resources. It is the key for functional security in the software level protection, and it means if we secure the operation system, we can secure all device, all devices can secure the whole network and ecosystem. This is the “Chain of Trust”.
Software level protection starts from operating system level which is the most critical component of Functional Security.
Nowadays, conventional operating systems (RTOSes) for IoT Endpoints implement multitasking and connectivity stack integrations and use cryptography stack. Are they enough to secure IoT device itself?
If existing OS/RTOS mechanisms are not enough, can we say operating systems are the weakest link in the security at the moment?
It is clear that we need secure operating systems first which implement universal security policies to secure the root of the ecosystem.
Secure Operating Systems protect the root of the ecosystem.
On the other hand, we could create an Operating System, and we could call it as “Secure” but for users or manufacturers, how can we trust an operating system whether it is secure enough?
In this case, a new question appears! "What" or "Who" could say whether our system (operating systems) is secure enough?
There are proven security rules and all they are collected under different “Certifications” (e.g. FIPS 140-2, PCI PTS) depending on the domain (e.g. military, payment systems) needs which can be the answer for “What” question. Therefore, a goal for a secure operating system must be meeting the Security Certification Criterion and requirements.
Evaluation of certification criterion on an operating system is not business of companies so it must be done by a third-party authority like a recognised Security Lab which is the answer to “Who” question.
PCI PTS: A Functional Security Certification
For safety-critical markets (e.g. automotive, medical), there are some well-defined “Functional Safety (not security)” certifications, and in the market, RTOSes mostly implement high responsive OS kernels (hard real-time) to meet safety requirements. However, it does not mean Real-Time Security. For example, a Memory/Stack-Overflow or writing into kernel address range mistakenly can easily break even RTOS kernel which can introduce a security leak, but RTOSes can be still certified as Functional Safe.
What about security? Do we have any options for security certification?
Interestingly, there is no well-defined functional security certification for IoT market yet. It is a critical problem, which needs to be solved first. Otherwise, each product will have its non-universal security policy.
On the other hand, some isolate markets have solid security processes and security certifications. The Payment Systems market is a great example; if you design and sell a Point of Sale (POS) product in the payment systems market, your end-product must be certified for PCI (Payment Card Industry), PTS (Pin Transaction Security), and this certification evaluation must be done by a “Recognised Security Lab”.
PCI PTS interests with logical and physical attacks and has generic functional security requirements; software level requirements are real-time protection requirements, which need to be handled by OS or User Applications at run-time.
Please see some of the PCI PTS requirements below:
A1 (Physical Protection): In case of the tamper, immediate erasure of any sensitive data that may be stored in the device.
B1 (Logical Protection): The device performs a self-test, which includes integrity and authenticity tests.
B7 (Logical Protection): Access to sensitive services requires authentication.
B17 (Logical Protection): Application Separation to avoid kernel/application interference.
At last, we have a mature domain in security with the experience of tens of years and massive motivation of payment security which protected by security certifications. The useful detail with Payment Systems is that payment systems topology is an exact topology for the Internet of Things; Secure and Connected devices (POS devices) and Cloud (Bank Servers).
Therefore, why don't we use the gains of the High-Security Payment System experiences in the IoT market?
What are the “Pains in the Market?
We could talk about Security in detail, but we need to discuss the pains in the market.
1. Security Knowledge pain
Manufacturers are not cryptographic level security experts, and they do not want to focus on cryptographic level security details. All they need is to handle their customers' expectations and finalise a (secure) product. Therefore, turnkey secure platforms could be a solution.
2. Certification Knowledge pain
Security evaluations by a security lab are not an easy process for Manufacturers. Manufacturers never want to battle with this process. Therefore, security-certified platforms could be a solution.
3. Certification Costs Pain
Evaluation process by a Security Lab is an expensive process for a manufacturer and manufacturers do not want to pay evaluation costs for each new product or modification. Therefore, certified turnkey platforms could be a solution.
IoT is an incoming storm, and the market is still looking for the right questions and answers. It is not easy for a manufacturer to know what to do, while lots of new concepts and technologies are making noise. Manufacturers are confused about what is the right for them; right certainly means “proven security” and “cost efficiency”.
At ZAYA, as an experienced team in Security and Safety Critical domains, we know the pains well, and we are here to remove the pains in manufacturing for security-critical products.
ZAYA: Functional Secure Operating System
In the heart of our solutions, you will find the ZAYA Functional Secure Operating System. ZAYA is designed according to Security and Safety Certifications from scratch.
ZAYA is a Secure OS and protects the whole device and its functionality from external attacks and keeps user applications in the secure side. ZAYA implements ‘Principle of least privilege’, so a user application is allowed to access only required resources and services. In this way, a user application cannot interfere or cannot break the whole system, while it is a function security feature which is also critical for "Functional Safety."
ZAYA has run-time mechanisms to protect the system, so once a violation occurs, the system gets the control and applies required security procedures depending on certification requirements. All of these security mechanisms remove the security knowledge pain.
ZAYA Certification Extensions
ZAYA is a generic Secure OS but depending on needs you can extend and customise its functionalities using "ZAYA Extensions".
A ZAYA Extension is like an add-on for ZAYA OS to handle application level security certification requirements. For example, in Payment Systems Certifications, you need to manage credit card user pin block formats which needs to be handled in application level.
Each ZAYA Certification Extension is designed for different security critical domains.
Using ZAYA secure kernel and certification plugins, you will have a Certified Turnkey Solution, which handles all certification requirements securely, so you do not need to think about the requirements in user application. Just focus on your custom user applications; It removes “Certification Knowledge” pain for Manufacturers.
Differently to the other conventional RTOSes, ZAYA designed modular; kernel, certification extensions and user applications are separate images so you can develop and upgrade your custom user applications separately without worrying about certification. You do not need to certify your product for each application modification; It removes certification cost pain.
Supported Platforms
While Arm’s TrustZone® on Cortex M profile processors announcement is exciting for Functional Security, you do not have to wait for TrustZone because ZAYA OS provides certification-ready functional security even on existing Arm architectures like Arm®v7-M (e.g. Cortex M3). In this way, you can transform your existing non-secure devices to 'secure products' without any hardware upgrade, so it is time and cost-effective for manufacturers.
ZAYA is also supporting Arm's “TrustZone® for Arm®v8-M” architecture and Platform Security Architecture (PSA) to provide a harmonically secure solution with the integration of software and hardware level protection.
ZAYA offers a smooth migration path from Arm®v7-M architecture to Arm®v8-M architecture. Using ZAYA’s modular design, you can transform your legacy device to secure device using ZAYA Arm®v7-M component, and once you upgrade your hardware with Arm®v8-M architecture, you can upgrade your software by replacing ZAYA's Armv7-M module with Arm®v8 module.
In conclusion, ZAYA is designed for Security-Critical environments from scratch, and the primary security reference of ZAYA in security domain is proven security certifications. It is modular, so you can easily customise ZAYA OS for specific security environments, and you can use it even on legacy devices to make your products secure.
If you would like to find out more and meet the ZAYA team, please contact: info@za-ya.co
Murat Cakmak
Founder, ZAYA