Low Cost PCB's Low Cost Components

Author Topic: Encryption in Assembler  (Read 861 times)

0 Members and 1 Guest are viewing this topic.

Offline branadic

  • Frequent Contributor
  • **
  • Posts: 635
  • Country: de
Encryption in Assembler
« on: August 14, 2017, 09:43:41 PM »
Hi to all encryption experts out there,

given a DSP running at 100MHz with:
- SRAM/OTP (program memory): 4k x 8bit
- Accumulator: 3x 48bit (ACCU A, ACCU B and ACCU C)
- RAM: 44x 48bit registers + 4x 48bit special function registers
- ALU: (COSZ)

and a very reduced instruction set:
- add, sign, sub
- resetWDG, powerOnReset, nop, stop
- bitC, bitS
- rad, clear, load, load2exp, move
- div, mult
- shiftL, shiftR
- jsb, jrt
- jcd, jCarC, jCarS, jEQ, jNE, jNEG, jOflC, jOflS, jPOS

being part of a sensor ASIC, with sensor frontend and interfaces such as SPI and I²C, I'd like to check out the potential to encrypt sensor data, before they are sent via interfaces. As you can see the DSP is only programmable using Assembler.
As I'm not a software expert nor familiar with encryption I'd like to get your feedback on what is possible. Thank you guys for all of your feedback.

-branadic-
Prema 5000 | Prema 5017 SC | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Keithley 181, Prema 5017 SC, 34401A, 34410A, HDO6054, Keysight 53230A and other goodies at work
 

Offline DrGeoff

  • Frequent Contributor
  • **
  • Posts: 621
  • Country: au
    • AXT Systems
Re: Encryption in Assembler
« Reply #1 on: August 14, 2017, 09:52:09 PM »
Encryption itself is not too difficult. If you can use a block cipher then AES128 would probably work as it was designed for ease of implementation (I have written versions of it in assembler for PIC16 chips) and is fast and efficient.

However, the key management part of it will be where the thought needs to be applied. An encryption system needs to have strong key management to be able to handle assigning and loading of new keys, prevention of revealing the keys, handling a compromised key etc etc.

Was it really supposed to do that?
 

Offline branadic

  • Frequent Contributor
  • **
  • Posts: 635
  • Country: de
Re: Encryption in Assembler
« Reply #2 on: August 14, 2017, 11:34:16 PM »
DrGeoff, can you share, maybe via PN, an example with me how you have impementend the block cipher in assembler? Sharing the key can be done one different ways:
1. I have input registers, that can be used via SPI/I²C to give the sensor a new key. Thus the master (microcontroller) gives the key to the sensor (slave)
2. A fixed key is programmed into the assembler code and delivered together with the sensor unit, like a licence key on a CD.

-branadic-
Prema 5000 | Prema 5017 SC | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Keithley 181, Prema 5017 SC, 34401A, 34410A, HDO6054, Keysight 53230A and other goodies at work
 

Offline Ash

  • Regular Contributor
  • *
  • Posts: 76
  • Country: au
Re: Encryption in Assembler
« Reply #3 on: August 14, 2017, 11:54:53 PM »
Hi Brandic,

Like DrGeoff said, the encryption is quite possible.

The real problem / question why are you encrypting? What problem are you trying to solve by adding the encryption?

Are you trying to prevent others seeing data over an insecure channel?
Are you trying to ensure that is isn't corrupted?
Are you trying to verify that the data is authentic and/or current (not replayed)?
Are you trying to ensure that only a specific controller can command the sensor?
Are you trying to enforce some kind on licensing restrictions?
Are you trying to hid the existence of the sensor?
Some other reason?

This will change how you need to approach the problem. For instance, if you have an insecure / untrusted communications channel (eg your I2C/SPI registers which I can read with an Oscilloscope), you can't just send the keys over it because then the keys have been compromised and your encryption becomes pointless.  To counter this you need a much more complicated key exchange process (like Diffie-Hellman for instance).

Perhaps if you could explain what you think you want the encryption to solve we could better advise you.  :-//

Also, standard warning for these things - rolling your own encryption is notoriously difficult to get right.

Ash.


 

Offline Ash

  • Regular Contributor
  • *
  • Posts: 76
  • Country: au
Re: Encryption in Assembler
« Reply #4 on: August 15, 2017, 12:04:53 AM »
and a very reduced instruction set:
- add, sign, sub
- resetWDG, powerOnReset, nop, stop
- bitC, bitS
- rad, clear, load, load2exp, move
- div, mult
- shiftL, shiftR
- jsb, jrt
- jcd, jCarC, jCarS, jEQ, jNE, jNEG, jOflC, jOflS, jPOS

Just noticed a lack of bit-wise operators - AND / OR and especially XOR. Without these you'd have to resort to look up tables for each operation and that would be pretty slow and memory hungry..

Xor is used extensively in a lot of crypto.

Ash.
 

Offline branadic

  • Frequent Contributor
  • **
  • Posts: 635
  • Country: de
Re: Encryption in Assembler
« Reply #5 on: August 15, 2017, 12:32:38 AM »
There are different reasons to encrypt sensor informations:

Security and warranty:
Only trusted and no third party sensors are allowed to be used, where the sensor is a component of a superior system. You want to make sure that sensor values are from a valid sensor. Currently the sensor delivers information via digital interface to a host controller and as you said you can hack the interface simply by an oscilloscope and replace the sensor by something else for example a cheap duplication of an expensive sensor. But what if this sensor data values are already encrypted and the sensor can identify itself? We are not talking about a simple temperature sensor, but complex multi-sensors.

Next point is all this IoT stuff. You want sensor data encrypted as soon as possible before they are within "THE CLOUD". Each sensor can also be used to harvest personal data but also process data. This process data on the other hand can be used to monitor wether you treat a machine out of specs, right? On the other hand companies want to benefit from all this newish IoT rubbish, so sensor data need to be encrypted to make sure that only allowed persons can see the sensor values.

So yes, the first four arguments are the main reasons why I ask for encryption.

Quote
Are you trying to prevent others seeing data over an insecure channel?
Are you trying to ensure that is isn't corrupted?
Are you trying to verify that the data is authentic and/or current (not replayed)?
Are you trying to ensure that only a specific controller can command the sensor?

-branadic-
« Last Edit: August 15, 2017, 12:40:17 AM by branadic »
Prema 5000 | Prema 5017 SC | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Keithley 181, Prema 5017 SC, 34401A, 34410A, HDO6054, Keysight 53230A and other goodies at work
 

Offline branadic

  • Frequent Contributor
  • **
  • Posts: 635
  • Country: de
Re: Encryption in Assembler
« Reply #6 on: August 15, 2017, 12:52:34 AM »
There are different versions of the ASIC. In the first version the bitwise operations are missing. In another version bitwise operation such as not, and, or and xor are available. So as far as I understand you this is a good reason to switch over to this version for encryption?

-branadic
Prema 5000 | Prema 5017 SC | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Keithley 181, Prema 5017 SC, 34401A, 34410A, HDO6054, Keysight 53230A and other goodies at work
 

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 8682
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Encryption in Assembler
« Reply #7 on: August 15, 2017, 02:37:22 AM »
What sample rate of data?

100MHz clock speed is irrelevant to the ability to perform encryption; but to do it in real time, that's where the interesting questions lie!  8)  If it ends up taking 10k cycles to encrypt a sample, and the sample rate is, say, 44.1kHz, you have a bit of a problem there.  If it's a few lazy samples per second, it seems unlikely to me that an even more aggressively simplified ALU would have difficulty doing it (maybe not a SUBLEQ machine, but other than that..).

What about physical access to the chip?  If the key is transmitted in the clear via I2C, that's rather counterproductive.  A hard coded key provides security (the chip itself must be reverse-engineered*), but once the key is discovered, it's all over (say by brute force, cryptanalysis, or reverse engineering).

*Unless a buggy command allows leaking/dumping the address space, or something like that.  Which is a very common means of access to OTP and mask ROM devices, so it's worth investigating.

Also, if it's OTP instead of mask ROM, an attacker could write additional bits into the program, with unpredictable (potentially insecure) results.  Erasing OTP would be much harder, though, on a similar scale as decapping and reverse-engineering I think.  Write attacks aside, OTP should be pretty good.

What's the threat model?  Are critical backend systems exposed to the sensors, so that an attacker spoofing a sensor is dangerous?  Or is it a data privacy thing, where the breech of a single sensor is an individual privacy problem, but not a global one, while a breech of all sensors would be very bad?

The sensors could be made with individual (non sequential!) serial numbers, and that used as a keyphrase for the encryption.  The serial number could be hashed, then transmitted as a passphrase, to the backend.  You'd need a record of every serial number produced, but that's not a big burden of data, these days.  This would help limit the extent of privacy breech.

Tim
Seven Transistor Labs, LLC
Electronic Design, from Concept to Layout.
Need engineering assistance? Drop me a message!
 

Offline branadic

  • Frequent Contributor
  • **
  • Posts: 635
  • Country: de
Re: Encryption in Assembler
« Reply #8 on: August 15, 2017, 03:23:23 AM »
The sample rate is in the order of <100 samples per second, up to 8 different sensor values each 24bit long.
A hard coded key is only possible by programming the key into the OTP. I have no access to the siliconn fabrication.
I know, nothing is really save, it's only a matter of effort to hack almost everything, but having no security attributes at all is ignorant.

Yes, it's a privacy thing, if you would like to name it like this and I'm just checking what is possible and what's impossible with the given hardware. I'm pretty sure that future sensors especially for IoT will have encryption but also identification attributes such as physical unclonable functions (PUF) included.

So given I program some individual ID into the sensor, that is is provided together with the sensor to the customer, it should be possible to encrypt sensor data in AES128 with the given hardware?

-branadic-
Prema 5000 | Prema 5017 SC | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Keithley 181, Prema 5017 SC, 34401A, 34410A, HDO6054, Keysight 53230A and other goodies at work
 

Offline DrGeoff

  • Frequent Contributor
  • **
  • Posts: 621
  • Country: au
    • AXT Systems
Re: Encryption in Assembler
« Reply #9 on: August 15, 2017, 07:22:36 AM »
The sample rate is in the order of <100 samples per second, up to 8 different sensor values each 24bit long.
A hard coded key is only possible by programming the key into the OTP. I have no access to the siliconn fabrication.
I know, nothing is really save, it's only a matter of effort to hack almost everything, but having no security attributes at all is ignorant.

Yes, it's a privacy thing, if you would like to name it like this and I'm just checking what is possible and what's impossible with the given hardware. I'm pretty sure that future sensors especially for IoT will have encryption but also identification attributes such as physical unclonable functions (PUF) included.

So given I program some individual ID into the sensor, that is is provided together with the sensor to the customer, it should be possible to encrypt sensor data in AES128 with the given hardware?

-branadic-

AES128 is a block cipher, and encrypts in 128 bit blocks. You need to take this into account with your interface protocol. If only one block per message is required then you should probably include a unique changing number or some other bits that are unique to the message so that each encrypted block that carries the encrypted data is different. Otherwise an attacker could simply obtain a set of values for each bit of sensor stimulus and send these, effectively bypassing your encryption.

As some have suggested, it is more advantageous to use a diversified key rather than a master key for all crypto operations. Diversification uses a common key that is present in all devices and this key is used to encrypt something unique within the device (such as serial or ID number) which is then subsequently used as a unique key for that device. This means that no two devices will ever use the same key, however the sender and receiver must know the deviceID in order to decode the message. The inclusion of deviceID in the message may already be part of the interface protocol.
Was it really supposed to do that?
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 12419
  • Country: nl
    • NCT Developments
Re: Encryption in Assembler
« Reply #10 on: August 15, 2017, 07:43:43 AM »
As some have suggested, it is more advantageous to use a diversified key rather than a master key for all crypto operations. Diversification uses a common key that is present in all devices and this key is used to encrypt something unique within the device (such as serial or ID number) which is then subsequently used as a unique key for that device. This means that no two devices will ever use the same key, however the sender and receiver must know the deviceID in order to decode the message. The inclusion of deviceID in the message may already be part of the interface protocol.
My gut feeling says this is a bad idea because the device ID is (usually) something you can read from the device. If you use that to create a key then part of the key is known to an attacker.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline DrGeoff

  • Frequent Contributor
  • **
  • Posts: 621
  • Country: au
    • AXT Systems
Re: Encryption in Assembler
« Reply #11 on: August 15, 2017, 07:48:55 AM »
As some have suggested, it is more advantageous to use a diversified key rather than a master key for all crypto operations. Diversification uses a common key that is present in all devices and this key is used to encrypt something unique within the device (such as serial or ID number) which is then subsequently used as a unique key for that device. This means that no two devices will ever use the same key, however the sender and receiver must know the deviceID in order to decode the message. The inclusion of deviceID in the message may already be part of the interface protocol.
My gut feeling says this is a bad idea because the device ID is (usually) something you can read from the device. If you use that to create a key then part of the key is known to an attacker.

Yes, most probably. However the deviceID is encrypted with a master key to produce a device specific key. The master key is unknown and it makes messages from each device unique. Without diversification you have a risk that breaking one set of messages will allow all sensors to be replaced with clones. Just as the master key can be burned into the device, so too can a 128 bit unique ID that is not readable externally but is known to both ends. That is what I would be suggesting.

Was it really supposed to do that?
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 1438
  • Country: us
Re: Encryption in Assembler
« Reply #12 on: August 15, 2017, 08:19:58 AM »
AES128 is a block cipher, and encrypts in 128 bit blocks. You need to take this into account with your interface protocol. If only one block per message is required then you should probably include a unique changing number or some other bits that are unique to the message so that each encrypted block that carries the encrypted data is different. Otherwise an attacker could simply obtain a set of values for each bit of sensor stimulus and send these, effectively bypassing your encryption.

Block ciphers are usually implemented in a mode that fixes this by manipulating the cipher initial value.  Usually this is done either via block chaining or counter mode.  Note that you may have to be careful to avoid counter reuse and similar problems with chaining. In embedded applications this may be quite difficult, since someone can power cycle your device at will.  It may be better to bypass this issue by using single use AES keys and diffie hellman key exchange.  But then you need to implement some public key algorithms which are more complicated, and key distribution is still a problem.

If you have to be tamperproof your problem is much harder.  Power channel attacks are often very easy to implement and very difficult to defend against.
 

Offline branadic

  • Frequent Contributor
  • **
  • Posts: 635
  • Country: de
Re: Encryption in Assembler
« Reply #13 on: August 15, 2017, 08:29:38 AM »
Thanks for the reply. I call myself a "theopractitioner", a good mix of theory and practice, so lets get to practice, shall we? I don't want a complete solution, but a hint on how I can implement it into my environment.

-branadic-

BTW:The sensor values are stored in result registers that can be accessed via SPI or I²C.
Prema 5000 | Prema 5017 SC | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Keithley 181, Prema 5017 SC, 34401A, 34410A, HDO6054, Keysight 53230A and other goodies at work
 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 411
  • Country: ca
Re: Encryption in Assembler
« Reply #14 on: August 15, 2017, 08:41:05 AM »
Only trusted and no third party sensors are allowed to be used

If someone breaks into a sensor, this will be enough to sniff the code and the key and then to be able to impersonate any malicious device as the sensor. Then you can build any number of copies of this malicious device which can pose as valid sensors all around the world.

If you want to prevent this scenario, you need to issue a cryptographic certificate to each server. The certificates should expires unless renewed and you should be able to revoke compromised certificates.

And do not store master/system key or anything of that sort inside sensors.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 7182
  • Country: cn
  • Power Electronics PhD Candidate
Re: Encryption in Assembler
« Reply #15 on: August 15, 2017, 09:25:31 AM »
So basically this is just for profit -- to prevent knock off sensors from being interfaced to your controller.
Any encryption without random factor can be easily cracked -- AES is harder, and XOR is easier, but eventually they can be cracked relatively easily as long as someone can reconstruct sensor data from output of the system, and compare with captured bus data.
A system can be much harder to crack with a random factor -- an RNG in the ASIC, and a hash engine to compute hash of random key, while the random number is also sent to sensor, which has a same hash engine (this is how HMAC authentication works), and the hash result can be used as common symmetric key of your real encryption algorithm.
As long as the SHA seed key (used to block encrypt RNG) is not compromised, the system is virtually impervious to attack -- even if someone worked out the symmetric key, the key will be voided and a new one will be generated the next time, so the key is rendered useless.
The ideal is built on the fact that reverse hash seed is much harder than reverse a symmetric key, and as long as you use a strong enough hash algorithm (SHA256, for instance), the system is reasonably secure.
SIGSEGV is inevitable if you try to talk more than you know. If I say gibberish, keep in mind that my license plate is SIGSEGV.
 

Offline Ash

  • Regular Contributor
  • *
  • Posts: 76
  • Country: au
Re: Encryption in Assembler
« Reply #16 on: August 15, 2017, 10:02:03 AM »
There are different versions of the ASIC. In the first version the bitwise operations are missing. In another version bitwise operation such as not, and, or and xor are available. So as far as I understand you this is a good reason to switch over to this version for encryption?

Definitely, you will find it difficult / very inefficient to implement any crypto without XOR.

There are different reasons to encrypt sensor informations:

Security and warranty:
Only trusted and no third party sensors are allowed to be used, where the sensor is a component of a superior system. You want to make sure that sensor values are from a valid sensor. Currently the sensor delivers information via digital interface to a host controller and as you said you can hack the interface simply by an oscilloscope and replace the sensor by something else for example a cheap duplication of an expensive sensor. But what if this sensor data values are already encrypted and the sensor can identify itself? We are not talking about a simple temperature sensor, but complex multi-sensors.

Next point is all this IoT stuff. You want sensor data encrypted as soon as possible before they are within "THE CLOUD". Each sensor can also be used to harvest personal data but also process data. This process data on the other hand can be used to monitor wether you treat a machine out of specs, right? On the other hand companies want to benefit from all this newish IoT rubbish, so sensor data need to be encrypted to make sure that only allowed persons can see the sensor values.

Ok, thank you that helps a lot. I don't consider myself and expert in this stuff, but I've done a bit..

One thing that no one has mentioned yet is that many countries consider encryption to be controlled in some way. You should work out what that means for your situation. For instance, in Australia we have to seek export approval / registration for cryptographic hardware and the definition is very broad. Whether you agree with the restrictions or not, they still apply to you so ignore them at your peril.

Encryption and Authentication are two different things.  A block cipher (AES for instance) will not prevent me from modifying data on the wire. I may not know what the data is, but I can flip bits and your consumer won't know the difference unless you have an additional layer of authentication.

HMAC is a good way to do authentication, it is a hashing process that can use a number of different hashes (most commonly one of the newer SHAs) and an authentication key. This key should not be the same as the encryption key (at least that's my understanding).

Also, as Blueskull mentioned, random numbers are important. Block ciphers take initialisation vectors and it is very poor form to reuse one. You will need a source of random. This can be a pseudo random number generator (make sure it is crypto grade stuff) and periodically seed it from a true random source (external event timing if nothing else)

You will have to format your data into a packet, this packet should contain a header with the block cipher IV, then you add your encrypted sensor payload, then you HMAC the entire thing (header/IV/cipher text) and add the hash.

You will need to work our how you can implement keys, you will probably need unique random keys programmed at the factory. Then you will probably want (as Blueskull suggested) a key exchange process that uses this data to generate session keys that are used for the actual encryption / authentication. Regenerate these keys periodically. This is not as easy as it sounds to do securely.

As for actual implementation, this is a bit more tricky. I can only point you to implementations that are commonly available on the Internet. You will have to work our how to map this into your assembly / system.

I would suggest that you try to implement everything on a PC or similar first and then compare the outputs against know good implementations with a large set of test vectors. This will tell you that your implementation is "correctly" manipulating the bits. Then move to assembling the pieces and port to your sensors.  Do you have an emulator? Given the simple instruction set, perhaps you could hack one up that is sufficient to do crypto testing. This will also give you a good handle on cycle-counts needed to do the work, and this might be a problem for you. Some algorithms are more efficient in software than others. But I'm no expert on that.

Hope that helps.
Ash.
 

Offline DrGeoff

  • Frequent Contributor
  • **
  • Posts: 621
  • Country: au
    • AXT Systems
Re: Encryption in Assembler
« Reply #17 on: August 15, 2017, 10:45:30 AM »
So basically this is just for profit -- to prevent knock off sensors from being interfaced to your controller.
Any encryption without random factor can be easily cracked -- AES is harder, and XOR is easier, but eventually they can be cracked relatively easily as long as someone can reconstruct sensor data from output of the system, and compare with captured bus data.
A system can be much harder to crack with a random factor -- an RNG in the ASIC, and a hash engine to compute hash of random key, while the random number is also sent to sensor, which has a same hash engine (this is how HMAC authentication works), and the hash result can be used as common symmetric key of your real encryption algorithm.
As long as the SHA seed key (used to block encrypt RNG) is not compromised, the system is virtually impervious to attack -- even if someone worked out the symmetric key, the key will be voided and a new one will be generated the next time, so the key is rendered useless.
The ideal is built on the fact that reverse hash seed is much harder than reverse a symmetric key, and as long as you use a strong enough hash algorithm (SHA256, for instance), the system is reasonably secure.

The OP's question was simply about implementing encryption in assembler. There are really no details about the system, protocols, key management or other architecture that can be considered at this time. This is left to the OP to describe or solve.

From the details so far, encryption is not being used for security of message contents, but authorisation of device.
Whether this is a good approach would require a lot more system architecture and interface protocol details. There may be other mechanisms that could achieve the outcome.

It should also be noted that encryption algorithms have a shelf life. This is defined as the amount of time that the algorithm is expected to be secure against brute force attack. With computing technologies improving rapidly the shelf life for algorithms such as aes128 might be significantly shortened.
Was it really supposed to do that?
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 12419
  • Country: nl
    • NCT Developments
Re: Encryption in Assembler
« Reply #18 on: August 15, 2017, 10:50:22 AM »
For authentification a hashing algorithm combined with a challenge-response system might be a good idea.
« Last Edit: August 15, 2017, 10:51:53 AM by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf