Introduction to SoC
Security Fundamentals; SoC Security Tutorial
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