Introduction to SoC Security Fundamentals; SoC Security Tutorial
-Aviral Mittal avimit att yahu dat cam.
https://www.linkedin.com/in/avimit/
SITE HOME

Scope:
This techerature introduces the security aspect of the SoC (System on Chip). Why it is important, where it is needed, and how a SoC (System on Chip) may be secured to fend off from attacks form hacker(s). This techerature assumes that a SoC is ARM processor based.
This document's scope is limited to how the security of the SoC may be compromised via the JTAG/SWD port, and how it may be prevented. For more general techerature on SoC Security Click Here:
This document also describes what is commonly known as "Debug Authentication". How a debugger is authenticated to access the SoC memory legitimately on a Secured System on Chip.
Target Audience:
Could be anyone. This techerature is in a very simple language, and avoids any difficult words. Anyone who is curious about Security in electronic systems may read it. The basic fundamentals explained here also apply to many other electronic security systems that are being used today. (Nov 2019). If you are curious about 'Certificate based authentication', again this techerature might help.

Why would a hacker attack a SoC (System on Chip)?
There can be various reasons. One of the objectives can be to steal SoC assets. But wait a minute, what are SoC assets?
One of the assets on the SoC is the embedded software. Embedded software contains proprietary algorithms very often protected by patents. Obviously these are precious, and must be protected.
Then another example of assets could be any data stored in the SoC.

How can a hacker get to the software which is inside the SoC?
One very easy way could be via the JTAG/SWD port. OK, so let me introduce the whole picture here.
Every modern SoC has a JTAG port or a Serial Wire Debug (SWD) Port. This port is there for an external device such as a 'tester' or a 'debugger' to get attached to the SoC, to be able to either debug the SoC or to be able to to download software code into the SoC's memory. To summarize, it is possible to get to the internal memory of the chip and read the memory locations or write to the memory locations using an external device connected to the SoC's JTAG/SWD port.
Now, the SoC can be designed/manufactured by a company A, and the software(s) that runs on it may be sourced from various other companies B, C or D in addition to A. This means that a typical SoC may have 'assets' from multiple software companies on it.
The software itself may be encrypted and stored off chip in some Flash memory. But while it is running on the SoC it will be in decrypted form in the SRAM. Now if an external device connected to JTAG/SWD port can access the SRAM, it can get the decrypted code.

So how can the SoC 'assets' be protected from an attack via the SoC's JTAG/SWD port?
One very simple technique will be to disable the JTAG/SWD port, after all the testing has been done, and the SoC is on a end-product ready to be shipped to the end customer. Now since the external JTAG/SWD port has been permanently disabled in the end product, the SoC assets are safe, from this point of view.
However this is a problem because
1. This would mean that a customer device can not be debugged even by the manufacturer or authentic parties, if there is a bug in the device which is out with the customer/end user.
2. This would also introduce a limitation that the designer/manufacturer or any authentic party wont be able to 'update' the firmware on the device when the device is with the customer/end user, as the JTAG/SWD port is the primary means to enable such a firmware update.

So what is the solution?
The solution is to
1. Keep the JTAG/SWD port unlocked throughout the product life cycle.
2. Secure the JTAG/SWD port so that only 'authentic' users can connect to it. This means that the JTAG port is 'locked' on the device for normal accesses, and only opens up after a successful 'authentication' process has been completed which ascertains that the entity accessing the JTAG port is legitimate and has permissions to do so. This whole process of authentication of the JTAG port user is often termed as 'Debug Authentication'. How it is done is what this techerature is addressing.

There is one another problem:
Its not only that the 'tester' or the 'debugger' connected to the JTAG/SWD port that must be authenticated to be genuine, its also the SoC which must prove itself to be genuine, before the user can download their code into it. You don't want to download your patented software on a fake device.
This means the authentication has to be bi-directional. The 'debugger' attached to the JTAG/SWD port has to somehow prove to the SoC that it is genuine, and the SoC somehow has to prove it to the 'debugger' that it is genuine.

The best way for authentication is to use 'asymmetric cryptography'. Well don't be intimidated by the term 'asymmetric cryptography'. I wont go into details of it either, but will only briefly explain the application of it to our purpose. Well, cryptography in very simplistic terms is a method to encrypt a message using a 'key'. So if the 'key' is kept secret and is only known to the sharing parties, the sender can encrypt their message using this secret key, and the receiver can decrypt it using the same secret key. But now we have a problem. Before any communication happens, the sender and receiver somehow must agree on a 'secret' key, and share it. Sharing a key is a problem, you dont want to give away your key to someone as you never know what that someone will do with it. How the key will be shared is another problem. Here comes the 'asymmetric cryptography'. This method uses pair of keys, one is called the 'public key' which can be shared openly. The other is called 'private key' which has to be kept secret with only 1 party, this party, one that owns the 'private key' is the one which is trying to prove that they are genuine. All we need to know is the encrypted message generated using the private key can be de-crypted using the corresponding public key, which can be shared openly. So that is how the authentication may be established. How and why the public key de-crypts the message encrypted using private key is magic (for us), and we just got to trust, it happens.

So let us take an example.

Intel makes a SoC, and Microsoft wants to access the memory inside the Intel SoC for debug purpose or to put its code onto the Intel SoC, using JTAG/SWD port on the SoC.Remember that the accesses to the memory of the Intel SoC is locked by the Intel SoC for any JTAG/SWD accesses, and will only be opened to Microsoft or to any other vendor for access, once Microsoft or the other vendor is able to prove its authenticity.
Now, Microsoft debugger has to prove its authenticity, and it will happen like this:
Microsoft debugger requests access to Intel SoC's memory. For this Microsoft debugger may need access to something called 'JTAG Instruction Register'. This register is locked by default. So the Microsoft debugger will first send an 'Unlock JTAG Instruction reg' request to the Intel SoC
In response to Microsoft debugger request, Intel SoC will first produce a 'True Random Number' somehow using special circuits inside the SoC These circuits are called TRNG (True Random Number Generator). This random number is also commonly known as 'Cryptographic Nonce'. Its only ever used once. This Random Number will be used as a 'challenge message' and will be sent to Microsoft debugger using the JTAG/SWD Port. There is no confidentiality up till now. Some also call this random number as 'Nonce'. Its not a good idea to send the same 'challenge message' every time for authentication. Hence these are generated using TRNG on the fly to minimize risk, and each random number or 'challenge message' is only used once. Every time an authentication will be required, a new random number or 'challenge message' is generated.

Microsoft debugger will then encrypt this 'challenge message' using 'secret key', and send the encrypted message back to Intel SoC.
Intel SoC has the corresponding public key for the private key used by Microsoft. Intel uses this public key to de-crypt the encrypted 'challenge message' it has received from Microsoft debugger. Now Intel SoC compares the de-crypted challenge message, to then one it originally sent.These two should match, if the right private+public key pair was used, and if these match, Intel SoC grants access to Microsoft debugger.
These encrypted 'challenge message' is also called 'hash' of the 'challenge message'.

But here comes another problem. How does Intel SoC knows that he 'public key' it is using actually genuinely belongs to Microsoft. Huawei could have posed as Microsoft. So who determines that the 'public key' which Intel SoC thinks belongs to Microsoft actually comes from Microsoft? This is done by a third party called the 'Certificate Authority'. The job of  'Certificate Authority' is to Certify that the 'public key' that Intel is using, did actually come from Microsoft. The 'Certificate Authority' is the root of trust here. It issues a digital certificate, to tell Intel, that the 'public key+Microsoft' pair actually belongs to Microsoft. Microsoft on other hand would have provided its public key and its own identity to the Certificate Authority.

However the involvement of the CA seems to me as optional. If Intel/Microsoft can trust each other on public keys, then the role of CA becomes redundant.
But if in the above Intel/Microsoft example if CA is being used(as is generally the case), then while the Microsoft debugger is proving its authenticity to Intel SoC, Intel SoC will use a 'public-key' belonging to CA to first authenticate the CA's Certification of Microsoft's public key. This means that Intel SoC can just store one public key of CA to unlock multiple certificates issued by CA for multiple companies like Microsoft. The certificate issued by CA, for Microsoft, will sent by Microsoft debugger to Intel SoC. This certificate will contain Microsoft's public key as certified by CA.

So, now the secret key is ONLY known to Microsoft, and it has to protect it. This secret key will reside in the debugger device, but it will be protected rigorously. Its the queen bee on the hive, and if it is compromised, the whole secure system will fall through.
Now in the similar sort of way the Intel SoC would authenticate itself to the Microsoft debugger. Once two way authentication has been established, Intel SoC will open the doors for Microsoft debugger to be able to access certain regions of memory, which Intel would want to expose to Microsoft.
However if Microsoft is certain that the chips are genuine from Intel, then there may not be any need for this 2 way authentication.

This way of authentication where the requester requests access using security certificate issued by CA as described above is often termed as Certificate based Authentication and this method has very wide scope and adoption in a variety of electronic systems today (Nov 2019)

The secret Private Key Storage:
This key is usually stored in One-Time-Programmable memory or OTP memory on the SoC itself. Usually following the device manufacture, the secret key is programmed in the OTP of the device. This process of programing the key into the device is also called key provisioning.

One key message: The possessor of the secret 'private-key' in asymmetric scheme is always the one who is trying to prove its authenticity without revealing its private key. The verifier is the one who uses possessor's public-key to authenticate the possessor without having possessor's private key.

Click Here to Make Comments or ask Questions
                                                                      
NEXT => More on SoC Security Fundamentals

SITE HOME

-------------
Keywords:
Debug Authentication
Certificate based debug Authentication
SWD/JTAG port Authentication
Debugger Authentication.
What is Cryptographic Nonce
Asymmetric Cryptography