WP_Term Object
(
    [term_id] => 14
    [name] => Synopsys
    [slug] => synopsys
    [term_group] => 0
    [term_taxonomy_id] => 14
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 663
    [filter] => raw
    [cat_ID] => 14
    [category_count] => 663
    [category_description] => 
    [cat_name] => Synopsys
    [category_nicename] => synopsys
    [category_parent] => 157
)
            
arc v 800x100 High Quality (1)
WP_Term Object
(
    [term_id] => 14
    [name] => Synopsys
    [slug] => synopsys
    [term_group] => 0
    [term_taxonomy_id] => 14
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 663
    [filter] => raw
    [cat_ID] => 14
    [category_count] => 663
    [category_description] => 
    [cat_name] => Synopsys
    [category_nicename] => synopsys
    [category_parent] => 157
)

Securing embedded SIMs

Securing embedded SIMs
by Bernard Murphy on 02-20-2018 at 6:00 am

If you have a phone, you probably know it has a SIM card, for most of us the anchor that ties us into a 2/3-year plan with one network provider, unless you have an unlocked phone. Even then, you have to mess around swapping SIM cards if you travel overseas. Wouldn’t it be nice if the SIM was embedded and could be switched though an app or an over-the-air (OTA) update? That’s the promise of embedded SIMS. And they’re not just for phones. Since everything in the IoT now has the potential to communicate through cellular, you really don’t want to have to manage SIM cards in all those devices; that technology just won’t scale. Embedded SIMs make a lot more sense.

21995-sim-card-min.jpeg

Of course, some of these applications are also concerned about security – a lot. Take mobile payments, industrial applications wanting to switch to remote updates, entertainment apps requiring content protection and virtually any healthcare application. When you allow for software-based reconfiguration, locally or OTA, security concerns become paramount.

Which makes for some interesting wrinkles in the compute engine you want to use to build such a device. Naturally you want it to have a small form-factor and very low power. But now you also want best-in-class security. If you follow advances in security, these days that means a lot more than an on-board encryption engine. Synopsys has just released a new ARC Secure Subsystem with an integrated ARC SEM security processor to address just this need.

21995-sim-card-min.jpeg
In fact, Synopsys offers a range of security solutions to address different needs, from an EM-based option with special ISA extensions providing up to 7X acceleration over the base ISA for security functions, to a mid-range solution also offering side-channel resistance, to a comprehensive configurable security solution, to a full trusted-root solution.

21995-sim-card-min.jpeg

I’ll talk here just about some aspects of the comprehensive solution, if only as a refresher on just what getting serious about security takes. Naturally encryption/decryption is still a part of this, so for example on-the-fly so plain-text code/data is never stored. There’s support for multiple types of symmetric and asymmetric key methods. And the architecture supports the usual secure domain protections against attempts to access privileged memory, access through peripherals, access to keystores and so on. Synopsys also provides a true random-number generator (TRNG), based on a ring-oscillator. It really is a true random number generator (not pseudo-random so you have to work with them to personalize it to your needs.

What I find especially interesting is the work Synopsys have put into protection against side-channel attacks, methods many may have thought obscure and unlikely, but which become increasingly viable on remote or stolen devices. Take for example differential power analysis (DPA) in which you monitor slight variations on the power supply during encryption/decryption. The method requires some advanced statistical analysis on the part of the hacker but Cryptography Research have famously shown it can reveal keys very quickly. The SEM core overcomes this by adding power noise to the compute path, which can greatly extend the amount of time it takes to hack in this way (and therefore make it economically uninteresting). A similar trick is supported for timing-based probing.

Other side-channel defenses include latency-hiding in the channel between the processor and main memory. It may seem bizarre that hackers could deduce information just by monitoring the timing of memory activity, but they can. Smoothing out latencies in this path makes that a lot harder. To guard against fault injection (power spikes, radiation, …), integrity checking is performed along the data and instruction paths. And attacks through the JTAG channel are blocked through a challenge/response control mechanism (or you could blow a fuse-link to JTAG at the appropriate time).

An obvious question many of you will ask – what about Meltdown/Spectre immunity? According to Rich Collins (Sr. Segment Marketing Manager at Synopsys), the ARC SEM doesn’t have this problem – by design. He didn’t get into whether this is because the SEM doesn’t do speculative execution. But who would need that kind of performance after all in typical eSIM applications for this product?

Finally, what about customers? Something we’re going to have to get used to in this space is that no customers are ever going to give product endorsements on security-related technology. Even though you may be using the best security technology in the world, “security through obscurity” is still another valuable line of defense. If the hackers don’t know what core they are dealing with, they’ll often (apart from nation state hackers) move onto less challenging targets. You can watch the webinar HERE.

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.