-
First, it'll force enemy to allocate more resources for reverse engineering of the captured machine, and it also provides the opportunity for the manufacturer to charge the customer more
I forgot how much of a budget sink the military domain could be.
And I forgot about the case of reverse-engineering and protecting the design, as opposed to protect the signal in operation.
Thank you for the feedback about durability of components, I knew very few about it. -
In the multi-cultural environment, misunderstanding is a frequent event. We all are aware of that but sometimes one can make a mistake, me included. I think this is a terminology issue, when each party has different understanding of the same term.
I forgot how much of a budget sink the military domain could be.
And I forgot about the case of reverse-engineering and protecting the design, as opposed to protect the signal in operation.
In my understanding, encryption is a measure that protects the message from being read by an unintended recipient. In the ideal world, it's just not necessary because it brings inconvenience to everyone and effectively makes our live harder. While the other measures, such as check summing to protect message integrity, scrambling and other spectrum-shaping techniques to improve EMC, are not usually called encryption because the pursued goals are entirely different.
Perhaps that's the root cause. I really have no idea how encryption can help within a single machine. Perhaps the best use of cryptography in that case would be a digital signing to prevent proliferation of counterfeit parts. That's my best guess, I'm just trying to be open-minded to extract a bit of sense from every puzzling question. Sorry if you read something that I was not intended to convey.
---
WBR
-
In the multi-cultural environment, misunderstanding is a frequent event. We all are aware of that but sometimes one can make a mistake, me included. I think this is a terminology issue, when each party has different understanding of the same term.
For my part, "Budget Sink" might have been abusive.In my understanding, encryption is a measure that protects the message from being read by an unintended recipient. In the ideal world, it's just not necessary because it brings inconvenience to everyone and effectively makes our live harder. While the other measures, such as check summing to protect message integrity, scrambling and other spectrum-shaping techniques to improve EMC, are not usually called encryption because the pursued goals are entirely different.
This helps finding the right questions, such as "in which context would the message be transported?", the classic "Which threat model should it be prepared for?"...
I assume checksumming is much more lightweight, and sometimes hardware-accelerated for even simple MCUs.Perhaps that's the root cause. I really have no idea how encryption can help within a single machine. Perhaps the best use of cryptography in that case would be a digital signing to prevent proliferation of counterfeit parts. That's my best guess,
Complex vehicles might be bus protocols like CAN in cars, maybe something else in an aircraft.
If there is no cryptographic signature, any passenger close enough to the bus wires (piercing a hole) could send commands to control everything attached to that bus?I'm just trying to be open-minded to extract a bit of sense from every puzzling question. Sorry if you read something that I was not intended to convey.
Thank you for the meaningful answers to my silly questions.
it is possible that I am trying to solve a problem with the wrong approach, or solving something that is not a problem.
---
Josuah. -
A classic use case for in-system encryption is a flight data recorder for a military aircraft. It should record information including stuff likely to be of use to an enemy, such as positions and timing but which is needed for its primary purpose of accident investigation. Since the (encrypted) data, the encryption mechanism and the key will all be available to a hostile investigator, a ‘public’ key system can be used. The private key remains secure as it need never leave the accident investigation facility
-
In my understanding, encryption is a measure that protects the message from being read by an unintended recipient.
It can have more than one purpose.
Often, "secure" is a mix of three completely separate concepts:- Privacy – the information is secure from observation by others
- Authenticity – the information is from a trusted party
- Integrity - the information was not modified or constructed by an untrusted party
If the nonce is observable to outsiders, being able to see all messages in order, an attacker who knows the method of generating the nonces, can use each message to exclude a small part of the vast numeric phase space, making brute-force attack the more feasible there is data observed, and eventually break the integrity and authenticity.
Message privacy is a two-sided blade. On one hand, by making the messages private, the nonce is not visible to the outsiders, and it can help keep the information authentic even when privacy itself is not a particular goal. On the other hand, by making predictable data private, one can significantly hinder the security of the cryptographic algorithms, because the predictable data (especially at the beginning) can make it very cheap to exclude significant fractions of the (admittedly vast) numeric phase space for the algorithm, making it possible to brute-force the encryption open.
The simplest, and arguably most powerful form, of symmetric encryption is exclusive-ORing the message bits with a cryptographically secure, unpredictable sequence of bits (keystream) that both ends can generate, but outsiders cannot guess or derive even when they see all messages passed. This itself is quite lightweight, as you can imagine; it is the establishment of such keystreams between parties when outsiders can see all messages passed that is the hard part (and nowadays typically involves public key cryptography, which is quite slow/computation-intensive).
For things like intravehicular buses, in cars and aeroplanes and such, privacy is typically not an important goal; it is the authenticity and integrity that makes encryption desirable. Professional developers in this field also use the privacy as a social tool for those not versed in cryptography or secure design in general, because laymen intuitively associate secrecy with security. In computer systems the picture is much more complicated, so making things private/secret even they really don't need to be, is often a secondary goal with basis in human policies instead of information security per se.
As nfmax wrote above, military flight data on the other hand is something you do want to keep private/secret especially after a plane crash, so encryption is an absolute must there.
Edit: WTF? The editor adds an unnecessary close-list tag at the end of my post. Post-Edit: Oooh, at some point it added one at the beginning too, so now it works as expected. Weird. -
Editing was strange and different for me a couple of days ago (I've been on a short vacation so haven't been online much), but it has gone back to the old editor for me now.
-
Editing was strange and different for me a couple of days ago (I've been on a short vacation so haven't been online much), but it has gone back to the old editor for me now.
Yes, the old editor is much better than WYSIWYG, at least for me. I'm glad it's back
-
Often, "secure" is a mix of three completely separate concepts:
- Privacy – the information is secure from observation by others
- Authenticity – the information is from a trusted party
- Integrity - the information was not modified or constructed by an untrusted party
In French "Safety" and "Security" are both translated as the same word "Sécurité": something like "making sure that what intended happen" maybe.It is the establishment of such keystreams between parties when outsiders can see all messages passed that is the hard part (and nowadays typically involves public key cryptography, which is quite slow/computation-intensive).
So small microcontrollers are likely to be kept away from anything like TLS and most handshakes.For things like intravehicular buses, in cars and aeroplanes and such, privacy is typically not an important goal; it is the authenticity and integrity that makes encryption desirable.
Signing might not be as cumbersome as encryption to debug, but the overhead remains, and I imagine some communication bus involve small microcontrollers driving a simple function.
I imagine these will have a rather efficient core, eventually with 32-bit ALU, or perhaps crypto acceleration cores. -
Small microcontrollers without external support, yes. Encryption in general is not excluded, it will just typically use prearranged keys.It is the establishment of such keystreams between parties when outsiders can see all messages passed that is the hard part (and nowadays typically involves public key cryptography, which is quite slow/computation-intensive).
So small microcontrollers are likely to be kept away from anything like TLS and most handshakes.
However, there are cheap crypto chips like ATECC608A and ATECC608B that can do the handshake externally. With one of these, even public-key crypto is not outside small microcontrollers, even 8-bit ones.
Well, many of the currently used cryptographic hash functions and ciphers require either look-up tables or benefit from 32-bit binary operations (bit shifts, and/or/xor), so kinda yeah.For things like intravehicular buses, in cars and aeroplanes and such, privacy is typically not an important goal; it is the authenticity and integrity that makes encryption desirable.
Signing might not be as cumbersome as encryption to debug, but the overhead remains, and I imagine some communication bus involve small microcontrollers driving a simple function.
I imagine these will have a rather efficient core, eventually with 32-bit ALU, or perhaps crypto acceleration cores.
However, even AES can be implemented on a small 8-bit microcontroller. For example, see AVR-AES-faster at github. While the achievable bandwidth is relatively low compared to 32-bitters, it can definitely be done for e.g. CAN message data (payloads only, treating each message as one 128-bit block) or UART.
As I described earlier, the reason for such encryption may not be 'secrecy', but really authenticity and integrity, which is easier to get right with encryption than it is with pure message authentication codes (due to the nonce stuff I mentioned). -
However, there are cheap crypto chips like ATECC608A and ATECC608B that can do the handshake externally. With one of these, even public-key crypto is not outside small microcontrollers, even 8-bit ones.
I always forget to give a look at external chips.However, even AES can be implemented on a small 8-bit microcontroller. For example, see AVR-AES-faster at github. While the achievable bandwidth is relatively low compared to 32-bitters, it can definitely be done for e.g. CAN message data (payloads only, treating each message as one 128-bit block) or UART.
Surprising to see the amount of software pushing AVR chip outside what they are expected to be able to do.As I described earlier, the reason for such encryption may not be 'secrecy', but really authenticity and integrity, which is easier to get right with encryption than it is with pure message authentication codes (due to the nonce stuff I mentioned).
The use-cases are much more clear now.
Thank you all. -
I say for the most part because there is one gotcha: function pointers are only ever 16-bit, so if you try to take a pointer to a function stored in flash at an address greater than 0xFFFF, things won't work properly.
Function pointers should be 24 bit in the large memory model. If you can reproduce the issue you mentioned, please file a bug report at https://sourceforge.net/p/sdcc/bugs/
For me, the following works fine when compiled via sdcc -mstm8 --model-large:Code: [Select]void (*p)(void);
void dummy(void) // A function just at the 64K boundary to give some tolerance to array size below.
{
dummy ();
}
void f(void)
{
}
const char array[32725] = {0}; // Large array to force f above 64 K.
void main(void)
{
p = &f;
(*p)();
} -
Function pointers should be 24 bit in the large memory model.
Ah, so they are. I must admit last time I looked at it in detail was a few years ago, so maybe something changed since 3.x times. Or perhaps I'm mistaken. -
Thanks to this thread i remembered how nice STM8's are.
I dug out an STM8207RB a few days ago and it's now playing 8 channel Amiga protracker tunes mixed at 31kHz (in stereo with true panning) outputting 16 bit (ish) PWM at 125Khz, I did overclock to 32Mhz but so far i'm only using about 52% cpu time!
-
So ...
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything? -
So ...
I believe the STM8 was originally designed to only be marketed in China. It was later spread to other markets. It did well in China for a while, but local MCU makers are probably giving it a really hard time now. Maybe it has become non-viable.
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
-
Not sure if you've heard/read Jay Carlson's "The amazing 1$ microcontroller" article / post : https://jaycarlson.net/microcontrollers/
How unfortunate RP2040 did not make the list at the solid $1.00 price point, with >100,000 available to ship immediately from DigiKey -
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
I noticed a couple of weeks ago that the entire AF and AL lines had been marked NRND, but at that time the S and L lines had not been. But you're right, the entire STM8 line as has been now marked as NRND.
So much for their 10 year lifetime guarantee. Although maybe this means that they will continue to make them for 10 years from now.
An acquaintance of mine works for a company that uses a lot of STM8 in some of their product lines, and they have heard nothing.
I had a feeling something was up, though, what with the launch of the new STM32C0 line that they have been pushing marketing recently for as "a cost-effective alternative to 8-bit microcontrollers". -
NRND has no effect on existing users, and if you have a 10 year supply agreement in place, that should not be affected either. Sometimes a vendor will try to negotiate their way out of long term commitments that its hard for them to keep, but they would need to provide reasonable compensation. NRND just means use of the family is a dead end.I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
I noticed a couple of weeks ago that the entire AF and AL lines had been marked NRND, but at that time the S and L lines had not been. But you're right, the entire STM8 line as has been now marked as NRND. So much for their 10 year lifetime guarantee. Although maybe this means that they will continue to make them for 10 years from now.
An acquaintance of mine works for a company that uses a lot of STM8 in some of their product lines, and they have heard nothing.
I had a feeling something was up, though, what with the launch of the new STM32C0 line that they have been pushing marketing recently for as "a cost-effective alternative to 8-bit microcontrollers".
-
The RP2040 lacks a clock, a flash, and an LDO (to live off 5V straight from i.e. USB), and plenty of peripherals (which can be circumvented by the presence of PIO, that being said) and has a high amount of power drawn.
Still an interesting MCU depending on the use-case though.
I agree it would have been interesting to put it in the comparison though. -
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
I noticed a couple of weeks ago that the entire AF and AL lines had been marked NRND, but at that time the S and L lines had not been. But you're right, the entire STM8 line as has been now marked as NRND. So much for their 10 year lifetime guarantee. Although maybe this means that they will continue to make them for 10 years from now.
An acquaintance of mine works for a company that uses a lot of STM8 in some of their product lines, and they have heard nothing.
I had a feeling something was up, though, what with the launch of the new STM32C0 line that they have been pushing marketing recently for as "a cost-effective alternative to 8-bit microcontrollers".
Yes, price and availability of STM8 have worsened a lot, and there are now shiploads of pin-compatible alternates on offer, at lower prices.
The 8051 core is popular in Asia, and seems to have many vendors offering STM8 pinout variants, and many with better peripherals.
SiLabs have recently released their 5V wide Vcc 50MHz 8051's and smaller packages are coming in 2023.
-
The 8051 core is popular in Asia, and seems to have many vendors offering STM8 pinout variants, and many with better peripherals. SiLabs have recently released their 5V wide Vcc 50MHz 8051's and smaller packages are coming in 2023.
This looks interesting to me. I haven't messed with the 8051 for years. I will definitely check out these recent 8051-compatible chips. For my projects "full 5V I/O" is often required. -
Not sure if you've heard/read Jay Carlson's "The amazing 1$ microcontroller" article / post : https://jaycarlson.net/microcontrollers/
How unfortunate RP2040 did not make the list at the solid $1.00 price point, with >100,000 available to ship immediately from DigiKey
The extra $1 for QSPI FLASH busts the budget, but then you are getting two cores :-)