Half a year ago TrustCB took the responsibility of the certification of a large chunk of the global ticketing starting with operating the MIFARE v3.0 schema.
Now TrustCB has co-built, and is now operating, the Security Evaluation Scheme for IoT Platforms (SESIP). SESIP is the first building block to solve the IoT security evaluation problem: how to address so many different types of products, with each their own requirements?
The problem is not how to express the requirements such varied range of products: we have had the Common Criteria (CC) for decades and this has worked very well to adapt to all kinds of domains. The problem is also not how to evaluate with good to excellent assurance: we know how to apply and optimise the generic CC methodology to specific domains (even, and especially, in high-assurance areas such as smartcards). The problem also is not about optimising the evaluation and certification processes for predictably short time to certification with dedicated evaluation schemes.
The challenge is the sheer size of the domain. The leading chip designer ARM is talking about 100 billion devices in the coming 4 years. This translates to much more than 100.000 of device types per year. That is a lot, a big challenge to solve in steps. So we start first to look at the bulk of the IoT platforms underneath these products. Those only number in the 100s-1.000s per year. Much more “reasonable” to address 🙂 (Fair disclosure: I have been intimidated a few times by those number too, but we’ve found solutions for this.)
SESIP builds in our decades of experience with the CC, using what works (the assurance concepts) and reformulating what we really haven’t gotten to work (the CC part 2 SFRs).
The assurance in SESIP is simplified to a numbered range of assurance packages ITP1, ITP1+, … ITP3. Like the CC EALs, the higher the number, the higher the assurance. Unlike the EALs, the packages are close to the common assurance situations. ITP1+ for example addresses black box testing, without needing design information one can only gather from the developer. ITP3 translates the traditional smartcard evaluations as EAL4+ for use in new domains. These levels are already aligned with various up and coming other certification schemes.
Functionality is expressed in human-readable sentences. These can be translated to various not-so-human-readable versions such as the CC part 2 SFRs and any product-domain-specific language, in fact several of those translations are currently in the making. But the point is that the users of these IoT platforms, the people who make the IoT products, can actually understand what the platform they use can be trusted to do for them securely. This way, the IoT product developers can focus on their strength: making great products.
This scheme already has a lot of momentum in the field of security approval and is moving forward fast. Expect certificates to come fast.