Ensuring cyber security in embedded systems - building the digital fortress

Written by: Piotr Strzałkowski, expert in the field of embedded

What has the systems’ security in common with a fortress? How do the security systems work and why are they fundamental? Why shouldn’t we believe our third parties companies? To answer those questions, in this article we will discuss the topic of cyber security in automotive and embedded systems. In the end, there will be a bunch of tips and tricks which were useful in one of our projects for the automotive industry.

We specialize in developing and testing safety-critical systems. Check out what else we can do in the embedded field.

Fortress difficult to conquer

Security systems have always been a matter of human interest. People built fortresses to protect very important things: treasures, strategic staff and weapons, and most of all – human life.

The concept of protecting valuable information, treasures, and controlling access to selected lands is as old as the world. For example, In the medieval centuries, buildings called fortresses were used to protect lands and places of strategic importance. It is not an easy-peasy thing to design and build such a construction.

You have to adjust everything to the surrounding environment and current abilities. You have to think about:

1. Material which you use.
2. The shape/size of the constructions.
3. The size of defense elements.
4. The size and amount of offensive elements.

The system’s security is like a fortress (with a castle inside)

It is not easy to build a fortress. For a better understanding of the topic, let’s recall how the medieval fortresses looked like and were built. Generally, we can recognize the following elements in those types of buildings:

• the moat which surrounds the fortress,
• drawbridge through which residents can walk into the fortress,
• defensive gates which additionally protect selected parts of the fortress,
• defensive walls – which protect and surround the fortress,
• defence towers where for example archers are based,
• barbican – which is a special construction to protect the drawbridge against attacks.

All those elements are crucial and perform a specific role in the defence system. The lack of one of those diminishes the defence capabilities of construction.

What if you were responsible for building the fortress?

A good point to start is building a moat which should be as deep as possible and as wide as possible to make sure that crossing it without using a drawbridge is impossible or at least very hard. Do you agree?

Nevertheless, as always – the devil is in the details and the width of the moat should fit the capabilities of our army, for example to the range of archers or other war machines, to be able to attack the enemy behind defence walls.

Why is the moat so important?

Because it is our first line of defence against direct attack. The enemy would not have easy access to defence walls and gates. They would have to use sophisticated war machines to get in or to destroy them. When they break them, it would allow them to execute easier and launch different types of attacks on our fortress.

Let’s imagine a little island with defence walls surrounded by a moat, where our fortress is going to be built. The island is actually the “hardware”, for example, microcontroller where we’ll embed our software in the future.

Now you know why the HW topics are so important. Here are some key hardware-related elements that we must never forget:

• verify if read protections bits are properly set,
  Maybe this point sounds so simple, but most of the time we make mistakes on such topics. For instance, someone forgot to handle the new security registers in the microcontroller, when it was changed to one with more flash memory.
• verify if the microcontroller has required tamper protection for your project
  The tamper layer in the microcontroller or in secure elements is not bulletproof There are several techniques for getting rid of it. There are also several types of tamper layers – simple and harder to bypass. It is worth making a wise decision on which microcontroller to choose with what type of tamper layer.
• verify if the microcontroller has high-quality RNG and works fine for example in such moments as after power-up, reset,
  History shows that such HW components have internal defects, so testing them is a wise decision.
• read errata of microcontroller from a cyber security point of view – verify error in security modules and all events which can cause exceptions resets and so on.
  Having unhandled exceptions or other reset mechanisms in the system can be a potential vulnerability

Software/hardware (SW/HW) interfaces

After building a moat and some part of defence walls the need is to build drawbridges and gates. This is another part of the fortress that requires special attention. That’s because all in and out traffic goes through the drawbridges and the gates. From the bandwidth point of view, these roads should be as wide as possible and without any obstacles such as gratings not to disturb the flow. The other way to allow undisturbed bandwidth is to build as many gates as possible.

However, again, the devil is in the details. If the gates and drawbridges are too wide, without proper protection they are a great temptation for the enemies to attack. It is easy to attack gates that are not protected or so wide that verifying the full traffic is not possible. That’s why we should add such constructions as barbicans and gratings to help protect all the drawbridges and gates in the fortress. Translating this story into our cyber security world: any unprotected system interface is asking for trouble and the goal is to reduce the surface of attack in our system, and not make it excessively wide.

To sum up – never forget to:

•   deactivate your JTAG or another programming interface,
•   if it is possible to activate protection mechanisms for all HW interfaces,
•   handle all possible exceptions,
•   put the greatest emphasis on testing the parts of code responsible for handling interfaces like: queues, ring buffers, DMA, copying data algorithms, headers checking algorithms, and CRCs.

If you are in doubt which part of the code should be tested the best, always be sure to deeply test the code. That is most exposed to the external environment (for example handles raw frames).

These activities reduce the surface of the attack in the parts of the system.

Cooperation with external builders

Building such a big construction as a fortress cannot be done by one man. To achieve the goal at the right time, you would need external help from third-party companies and it is completely normal. However, you must remember a very important thing.

Regardless of how big and famous the company which helps you is or how much you like people who work there when you hear them saying that their work was delivered to the highest quality and that all the required tests have been done internally – don’t take their word for it.

Eventually, it is you who takes responsibility for the solution. All the codes delivered should be tested by them or by you. If your supplier performed the tests, you should get access to the results in order to verify them and make sure that they were made as you requested and covered in the required scope. Don’t accept it when they say the results of the tests are confidential.

Remember, lack of tests or some spots in the scope did not happen because of the bad intentions of the supplier. The cybersecurity topic is quite new in the automotive industry and not many companies handle this topic properly yet. Moreover, there are other circumstances like deadlines and human errors. Of course, if a supplier would have their own methods and for some reason don’t deliver results of tests, finally, you must perform the software tests on your own.

Good to remember:

• if you notice that your supplier is not fluent with the SC topic, help them, it will be a benefit for both of you
• express your doubts when they claim that the delivered work is perfect,
• allocate enough time to verify delivered code or results of tests or to execute your own tests – in most cases, one or two weeks is not enough,
• if you can, request the person in charge to put the paragraph about delivering cyber-security tests for code into the cooperation agreement,
• remember the defects can appear at the integration level, not only in delivered components,
• finally, the pleasure of reporting a defect is on your side,

Why is the supervision of HW and SW after the development process so important?

When the fortress is finally ready the real adventure begins. That is the moment when the assumptions and work meet real threats. We need to make sure that our resources are ready for the fight. It is like in the army, we must train the knights, collect the required armor and weapon to sustain the stable protection of the fortress, and at the highest level.

We have to prepare the action processes, servers, software, hardware, and tools. Then continuously expand our knowledge of possible new threats. Mostly, this part of a project is underpaid and short of resources such as people, skills and time. When the real exploitable vulnerability appears, it definitely is not the right moment to:

• create procedures, that describe what should be done, and by whom,
• search for/through the right code repositories with code and whole tools to develop and test,
• search for/through documentation of ASIL levels, interfaces, lists of protection mechanism and lists of suppliers or check which part of code is open source,
• scroll CVE databases to find a forgotten vulnerability.

That is why you should always remember to:

• scroll CVE databases periodically,
• prepare required procedures in advance,
• prepare required SW/HW tools in advance,
• prepare of each project information about used tools and code,
• perform audits and simulate critical situations.

Summary

You have to remember that history shows that only a few fortresses were not defeated.

These which have survived had:

• sometimes a little bit of luck
• perfect location
• were periodically updated

But should we count on luck?

I hope you found the answer to the question, how to build your own digital fortress in this short text.

Are you looking for a technological partner to implement cybersecurity on your software? Piotr and his team will be happy to advise you on the process and support the implementation. Contact us and build your embedded software with us.