feature article
Subscribe Now

Security In and On the Application

Thirdwayv, Keyfactor, and Thales Focus on Layer 7

Internet-of-things (IoT) security seems to be passing through various phases as a topic. It started as, “Wait, what? I need security? But why???” Frankly, we probably haven’t moved completely out of that one, but we’ve made progress. Next comes, “What does security mean?” And that continues as well. But a third phase has started, and that’s one of, “OK, I get it, but how the heck do I implement this? Do I have to do the whole thing from scratch??”

Much of the, shall we say, remedial? focus has been on basic security as typically implemented in Layer 4 of the OSI stack. For example, the most common security in use is TLS, which is a standard riding on the transport layer – TCP, to be specific. (There’s DTLS as the UDP equivalent.) But a couple of announcements are interesting not simply because they’re new products to talk about, but because they both address security in Layer 7 and reveal something about the nuances of security.

App-Level Security

The first comes from a company called Thirdwayv. And they’re building application-level security. Why would that be fundamentally any different from normal Layer-4 security? Here’s the thing: as a message moves down the OSI stack (on the sending side) and back up the stack (on the receiving side), the security aspects protect the message payload only at and below Layer 4. Above that, the payload is in the clear. Someone with sophisticated tools (like the government, perhaps, or your favorite social media host) may be able to figure out what’s going on by tapping into the message at higher levels.

For instance, if you send a Facebook Messenger message, it is sent securely, and yet Facebook can access the contents because, in theory, they own the message up and down the stack. If they want to, they can see the message before it is encrypted. Which is why folks who really want security prefer “end-to-end” security: that’s security in the application layer. That’s what WhatsApp and Signal have (and what the original WhatsApp developers and Facebook – not to mention the government – have been rumored to be at odds over).

With app-level security, the application builds in its own security, not relying solely on the lower stack levels for that service. The message is encrypted before it ever leaves the application, so, in theory, only the application knows the message. The app can exchange keys with the recipient so that the recipient’s app can decrypt the messages. Unless someone can trap that key (presumably not sent in the clear), then no one outside the app can see the message. The only reason the recipient can see the message is because their instance of the app, having set up a session with the sender, lets them see it.

Thirdwayv can run over any transport mechanism (including more security), so it’s not tied to any specific implementation. Having started with Bluetooth (since Bluetooth can be rather promiscuous about connecting in the presence of multiple possible connections), they also cover NFC, powerline, and Ethernet. And the specific interactions they are trying to protect involve IoT devices communicating with the cloud under the assumption that the data will go first through a phone or a gateway and thence to the cloud.

They’ve come up with two separate products for two aspects of the security: setting up a secure connection for messages and giving app developers a toolkit for adding security to their application.

The first one is called SecureConnect. It handles the secure messaging by creating a tunnel between the sender and receiver. The session is authenticated, and messages are encrypted – all natively in the application, without relying on lower-layer services.

(Image courtesy Thirdwayv)

The second product, newly announced, is called AppAuth, and it gives the author of an application many choices for implementing tight or loose security. (Obviously, tight security involves more inconvenience to the user…) The author can require biometric or other authentication mechanisms, for example, before implementing particularly critical operations.

AppAuth also helps to protect the application and the platform on which the app is running by, among other things:

  • Making sure that the phone is “clean” – that, as far as it can tell, it hasn’t been compromised;
  • Making sure that the phone hasn’t been rooted – that is, that someone hasn’t put the phone in a privileged mode that allows monkeying with things that shouldn’t be monkeyed with;
  • Making sure that platform isn’t running an outdated, rolled-back version of the OS. OS updates often protect against newly discovered vulnerabilities, but phones can have their OSes rolled back – useful if there’s an unexpected glitch in the update. Problem is, a hacker may roll the OS back specifically to re-enable a vulnerability. 
  • Obfuscating the application code to make reverse engineering harder;
  • Protecting the application from interference from other applications. It can’t do anything about any malware on the phone – except to make sure it keeps its hands off the author’s app.

(Click to enlarge; image courtesy Thirdwayv)

The Thirdwayv software relies on a root of trust – preferably a hardware one, like a secure element (SE), which they say adds about $1.00 to the bill of materials. Absent an SE, they can implement the software equivalent and use that, with the proviso that a software version isn’t as secure as a hardware version.

Sign Here, Please

The second product comes from Keyfactor in an announcement of their integration with Thales’ hardware secure module (HSM) offering to provide what they call Keyfactor Code Assure. The problem being solved here is that of code signing.

Yeah, unless you’re writing for app stores, firmware, automotive, and medical industries, code signing may not be a part of your repertoire. The idea is that your code gets “signed” using a digital signature that incorporates a certificate. There’s a public key in the certificate, which means you can check the signature. But what about the private key, which is used to generate the signature?

This has apparently been the subject of either security weakness or coder hassle, and that’s what Keyfactor and Thales are trying to tighten up. The idea is that an HSM provides an opaque server for signing code. That server acts as a vault for certificates and keys, and they’ve added another layer of protection by locking those artifacts. Before they can be used, they must be unlocked – and the rules for doing so can depend on things like the privileges of a submitter or the time of day.

Like any secure process, the users can’t see what’s going on. They merely submit their code, and out comes the signature. The private key, used to generate the signature, never leaves the vault. The HSM can be accessed by local or remote machines; scripts don’t need to invoke API calls to make it happen. The idea was to limit how this affects a developer’s life.

(Click to enlarge; image courtesy Thirdwayv)

Now, with signed code, an end device – like an IoT device – can first run attestation to make sure that no one changed an application’s code before it was downloaded. This applies, of course, both to new downloads and to updates. If the code is different in any way, the signature check will fail. And because the private key is out of reach, then attempts to cover up a code change by regenerating a new signature should fail.

This affects only the packaged code, of course. Once unwrapped and running in a device, it’s theoretically still possible to change the code. Periodic in-memory checks are one way to make sure that, over time, the code being used remains the correct code, but that’s another topic entirely. The Keyfactor/Thales solution ends once the code has been accepted.

 

More info:

Keyfactor

Thirdwayv

Thales Group

Sourcing credit:

Jim Kamke, CEO, Thirdwayv

Vinay Gokhale, VP Business Development, Thirdwayv

Ted Shorter, CTO, Keyfactor

Mark Thompson, VP Product Management, Keyfactor

One thought on “Security In and On the Application”

Leave a Reply

featured blogs
Dec 7, 2023
Semiconductor chips must be designed faster, smaller, and smarter'”with less manual work, more automation, and faster production. The Training Webinar 'Flow Wrapping: The Cadence Cerebrus Intelligent Chip Explorer Must Have' was recently hosted with me, Krishna Atreya, Princ...
Dec 6, 2023
Explore standards development and functional safety requirements with Jyotika Athavale, IEEE senior member and Senior Director of Silicon Lifecycle Management.The post Q&A With Jyotika Athavale, IEEE Champion, on Advancing Standards Development Worldwide appeared first ...
Nov 6, 2023
Suffice it to say that everyone and everything in these images was shot in-camera underwater, and that the results truly are haunting....

featured video

Dramatically Improve PPA and Productivity with Generative AI

Sponsored by Cadence Design Systems

Discover how you can quickly optimize flows for many blocks concurrently and use that knowledge for your next design. The Cadence Cerebrus Intelligent Chip Explorer is a revolutionary, AI-driven, automated approach to chip design flow optimization. Block engineers specify the design goals, and generative AI features within Cadence Cerebrus Explorer will intelligently optimize the design to meet the power, performance, and area (PPA) goals in a completely automated way.

Click here for more information

featured paper

3D-IC Design Challenges and Requirements

Sponsored by Cadence Design Systems

While there is great interest in 3D-IC technology, it is still in its early phases. Standard definitions are lacking, the supply chain ecosystem is in flux, and design, analysis, verification, and test challenges need to be resolved. Read this paper to learn about design challenges, ecosystem requirements, and needed solutions. While various types of multi-die packages have been available for many years, this paper focuses on 3D integration and packaging of multiple stacked dies.

Click to read more

featured chalk talk

ROHM's 4th Generation SiC MOSFET
In this episode of Chalk Talk, Amelia Dalton and Ming Su from ROHM Semiconductor explore the benefits of the ROHM’s 4th generation of silicon carbide MOSFET. They investigate the switching performance, capacitance improvement, and ease of use of this new silicon carbide MOSFET family.
Jun 26, 2023
19,660 views