Should I get a Keysight DSOX6004A ?

[kcbrown]

This sounds exciting but the answer is always "it depends". In some cases such cryptographic protection can be circumvented. Example: Flir E4 thermal cameras (this forum has a couple threads on it).

I'll have to examine those threads.  Sounds interesting.

Secondly, hard coding the encryption keys is a poor practice. Keys can be compromised and require replacement, or may be other factors  that may dictate key rotation.

While that's true in some cases, in this case you have to choose between hardcoding the keys (and suffering through the problems that might arise in the event your private key is compromised -- this is why you treat them like crown jewels) versus putting the keys in a writable medium and thus compromising the entire point of using them in the first place.  Since private key compromise is extremely rare when the private key is properly taken care of (how often have you heard of a major signing authority's signing key being compromised?  It's happened but it's rare -- the internet's entire security infrastructure would be worthless otherwise), and since the entire point of the exercise is to prevent people from being able to circumvent the signature verification mechanism, it's obvious that in this case, hardcoding the public keys in ROM is the way to go.

One other thing: when you hear of a CA certificate being renewed, it's the signature that's renewed.  The public and private key bits remain the same.

Thirdly, different encryption keys may need to be used for different firmware types for devices that utilize the same hardware platform. Example: Keysight 1000x series Linux-based oscilloscopes.

This doesn't make any sense to me at all.  A cryptographic signature is a cryptographic signature.  It's the same irrespective of the platform it's generated on or verified on, or the operating system it's using, or anything else.  It's even independent of word length, endianness, and every other attribute of a processor.  And that goes for the keys, too.  They're just blobs of data in well-understood encapsulating formats.  The algorithms in use today are public and widely used, and the methods for using the keys are widely known and exactly specified.  This is so because they are intended to be universally used.

Now, you'd obviously have to write your bootstrap loader to target the CPU you're using, and the same is true of the firmware upgrader, but that's a very different problem from the keys themselves.

Remember, too, that there is a huge difference between the key material itself and its representation.  The latter can change while the former remains the same.  What would change the key material is a change to a new encryption algorithm.   But this, too, is an old and well-understood problem with well-understood solutions.  And see below.  For this use case, the company probably doesn't have to worry itself too much about it.

And once the public keys are in the flash memory, they can be found and substituted with the attacker's own public key, then the attacker can upload the altered firmware signed with the corresponding private key, Job done.   

Which is exactly why you hardcode them in ROM.

Engineering is all about compromises.  Here, the proper compromise is obvious.

These devices have a limited period of time during which the company's going to care about this problem anyway.  After that, it doesn't matter if the device ends up being "hackable" or not.  This means the company can change up their key material from time to time without any real consequence, and if an old key gets compromised the company doesn't have to care, as long as its used only for this particular type of purpose.

The company could even use a different key for each device model line, thus greatly limiting the damage that a key compromise would do.  There are lots of possibilities here as to how the company could manage its keys.  And none of them require that the keys be stored in rewritable form.

[Bud]

One other thing: when you hear of a CA certificate being renewed, it's the signature that's renewed.  The public and private key bits remain the same.

This is not necessarily true. Nothing technically prevents a CA to generate a new key pair. It is a business decision whether to retain the old pair or go with a new one.

Thirdly, different encryption keys may need to be used for different firmware types for devices that utilize the same hardware platform. Example: Keysight 1000x series Linux-based oscilloscopes.

This doesn't make any sense to me at all.  A cryptographic signature is a cryptographic signature.  It's the same irrespective of the platform it's generated on or verified on, or the operating system it's using, or anything else.

I invite you to examine the Keysight 1200x scope firmware packages. They have if i remember correctly 4 individual firmwares in a single package, each firmware destined for a specific scope model, and each one has a different public key inside. 

Moreover, the fact that they ship public keys with the firmware means they have the possibility to rotate keys if they need to! So to me this was done on purpose.

[Sighound36]

All I did there was use infinate persistance to highlight the trace.

[2N3055]

Here some images of the 8000 and the Wavepro going head to head last year and you can see the 8000 is not bad at all.

What I don't like in this picture is the focal point around the trigger level. On a good scope the (inevitable) trigger jitter should result in the edge of the signal being smeared out equally to the left and right. With a focal point you get a much thicker trace below and above the trigger point (and any rising/falling edges) than it is in reality so using a mask test is not going to give good results.

It is not trigger jitter. Trigger jitter with a rock solid signal can be completely compensated out, and all parts of waveform will overlap. You don't get this effect.
That is being used on absolutely every jitter measurement application out there.

We spoke about this before: if signal has a variation in rise time, and you overlay many captures over each other , you will get exactly this.
Trigger point will go through exactly the same point and up and down of trigger point you get hourglass kind of shape. Changes (modulation) in edge speed can be caused by many things..

That is basically same you get when you feed the scope white noise, or sinewave FM modulated with sinewave , just less pronounced. See attachments.

What would be interesting is to go to upper part of that shape and calculate horizontal histogram to see if that rise time modulation is deterministic or stochastic...
And mind you, that histogram doesn't have to be same as plotting histogram of risetime measurements. Parts of the edge below and above trigger point don't have to change at the same time...
Risetime measurement will look at whole edge, so if you start slow and then speed up, and if you start fast and slow down, risetime will be the same, signal won't.

It can also be an artefact of sinc interpolation. On scopes that support dot mode, you enable that and you know it's not interpolation artifact.

[nctnico]

Here some images of the 8000 and the Wavepro going head to head last year and you can see the 8000 is not bad at all.

What I don't like in this picture is the focal point around the trigger level. On a good scope the (inevitable) trigger jitter should result in the edge of the signal being smeared out equally to the left and right. With a focal point you get a much thicker trace below and above the trigger point (and any rising/falling edges) than it is in reality so using a mask test is not going to give good results.

It is not trigger jitter. Trigger jitter with a rock solid signal can be completely compensated out, and all parts of waveform will overlap. You don't get this effect.

No. The signal in the picture can be considered to be close to perfect; likely it has a risetime over or close to the abilities of the oscilloscope. Think about it in terms of noise that is always present on a signal; that needs to show as an even distribution on screen. With the 'hour glass' effect occuring you can tell the noise of the trigger point has been smeared out the wrong way and thus is showing a signal which does not represent the actual signal. The hour glass effect also has a negative impact on the ability to measure the next edge at the tens of picoseconds level because that edge will also be smeared out further.

You can try this yourself on a DSO which has an adjustable trigger threshold.

[2N3055]

No. The signal in the picture can be considered to be close to perfect; likely it has a risetime over or close to the abilities of the oscilloscope. Think about it in terms of noise that is always present on a signal; that needs to show as an even distribution on screen. With the 'hour glass' effect occuring you can tell the noise of the trigger point has been smeared out the wrong way and thus is showing a signal which does not represent the actual signal. The hour glass effect also has a negative impact on the ability to measure the next edge at the tens of picoseconds level because that edge will also be smeared out further.

You can try this yourself on a DSO which has an adjustable trigger threshold.

It is not TRIGGER NOISE. It is SIGNAL NOISE, that creates random changes to the shape of the signal in vicinity of trigger point.
If it where only trigger noise,  as you say, it would look exactly like this, with a thick uniform line.
Like this:



But it doesn't. Because noise contributes with it's harmonic content to slow up and speed up parts of the edge, making it nonuniform. Hence hourglas shape.

To demonstrate, clean pulse:



Same pulse with added noise:



It can be clearly seen that there are faster and slower edges in there... If you overlap them you get hourglass shape.

[nctnico]

Just try it with a DSO which has an adjustable trigger threshold (or a DSO which has a real trigger circuit and not one that is done in the digital domain resulting in an infinitely small threshold). The problem I'm describing is that the actual trigger point is being moved!

[3isenhorn]

Hello all,

Somehow I got lost in the interesting discussion, but I wonder if anyone has mentioned that it is important to test the unit yourself.

If I were buying something new in this price range, I would ask for a demo. The best device is the one I enjoy working with, nothing is more demotivating than regularly using a device that doesn't fit your workflow.
On the technical side, I firmly believe that A or B brands cannot afford to sell unreliable equipment.

[2N3055]

Hello all,

Somehow I got lost in the interesting discussion, but I wonder if anyone has mentioned that it is important to test the unit yourself.

If I were buying something new in this price range, I would ask for a demo. The best device is the one I enjoy working with, nothing is more demotivating than regularly using a device that doesn't fit your workflow.
On the technical side, I firmly believe that A or B brands cannot afford to sell unreliable equipment.

Good point, but was said at the very begining. But good to mention, because it all went sidevays...
Partially my fault, I will tr to stay on topic. Thank you!
Best,

[Caliaxy]

Just try it with a DSO which has an adjustable trigger threshold (or a DSO which has a real trigger circuit and not one that is done in the digital domain resulting in an infinitely small threshold). The problem I'm describing is that the actual trigger point is being moved!

That’s really hard to understand. No matter how you move the trigger point from capture to capture, the result is the same: the waveform translates horizontally on the screen. Thus, the edges of the pulses would be parallel. It’s hard to imagine how you would get a “hourglass” pattern centered at the trigger point without varying the rise time or adding noise.

[Caliaxy]

Oh, I can see it now: you trigger each capture at a different threshold and you plot it centered at the trigger point (so you also shift the waveform vertically). That would also create a hourglass pattern on the rising edge, with thicker horizontal traces. Is this what you are saying?

[2N3055]

Oh, I can see it now: you trigger each capture at a different threshold and you plot it centered at the trigger point (so you also shift the waveform vertically). That would also create a hourglass pattern on the rising edge, with thicker horizontal traces. Is this what you are saying?

Threshold is fixed. It is what you set your scope at the moment. If edge is linear, monotonic, and well autocorrelated  (meaning it will repeat to be exactly the same), and there is no scope jitter, you will get one single thin waveform, no matter how many million waveforms you overlap on top.

If superimpose noise on top of that signal you will start to have distortions to edge linearity, i.e. it will change the shape. From straight line it will change to parts of sine/cosine shape being added to it. That will mean that such distorted edge will reach same voltage threshold at different time than linear edge. As the scope aligns all trigger events on top of each other (that is by design, trigger point is scope's zero of U/t coordinate system) they will have trigger point exactly on top of each other (there is no other way, really). The rest of the curve will kinda hang in the air left and right, because it isn't the same as previous one.  Every single one will have different slope, but will have to pass trough same trigger point.
So you get hourglass shape.
Even with trigger jitter = 0.

Fact is Nico is partially right: because of noise in signal, there will be some trigger jitter in that waveform too. But it is not source of hourglass shape. Waveform itself is..

When you have trigger jitter, your whole waveform "jiggles" left and right, because trigger is wobbling left and right. It is not doing good job and it's timing is random.
This can happen if you have higher frequency signal superimposed on top of signal.
This can happen on a analog scope with a noisy trigger level pot.
Signal is smeared left and right.

[kcbrown]

One other thing: when you hear of a CA certificate being renewed, it's the signature that's renewed.  The public and private key bits remain the same.

This is not necessarily true. Nothing technically prevents a CA to generate a new key pair. It is a business decision whether to retain the old pair or go with a new one.

It's not just a business decision.  It's a practical one.

If you "renew" a CA certificate by generating a new key pair, then you get a discontinuity in signature verification by anything that needs to perform such verification against that CA.  In particular, you would not be able to use the new CA certificate to verify signatures generated prior to the "renewal", whereas with a proper renewal you would.  Since the entire point of a CA (in the internet infrastructure, at least) is to sign other certificates so that endpoints can validate those certificates when they're presented, such a discontinuity would cause a lot of disruption in the operation of endpoints that have to verify certificates that are presented to them.

Now, if your CA is special-purpose, like what we're talking about here, then most definitely you could generate a new key pair.  What I was referring to was public CAs like Verisign's, and I guess I should have said that explicitly.


Generally, "renew" means to use the same key material whilst updating the signature, while "regenerate" means to generate new key material.  Some customers where I work don't understand the difference, and sometimes regenerate their keys when "renewing" their CAs, with the end result being that their ability to manage their devices (which depends on their management node being able to verify the presentation certificates of their devices) stops cold.  Hilarity naturally ensues.  The pain of that experience quickly teaches them the folly of confusing "renew" with "regenerate".

I invite you to examine the Keysight 1200x scope firmware packages. They have if i remember correctly 4 individual firmwares in a single package, each firmware destined for a specific scope model, and each one has a different public key inside. 

Interesting.  But note that they do that by choice, not out of necessity (presumably -- if there's a use case where doing that is a necessity, I don't know what it is).

Moreover, the fact that they ship public keys with the firmware means they have the possibility to rotate keys if they need to! So to me this was done on purpose.

Sounds like it.

But shipping the keys themselves in the firmware itself?  If you do that, then you could just surgically replace those keys with your own and bypass the entire signature verification mechanism, no?   Keysight has probably thought of that and may have a chaining mechanism of some kind to prevent that.  If the keys are actually certificates then they'll be signed by something that presumably traces back to something that, hopefully, is immutable.  In any case, I suppose much depends on what those keys are used for.


Having multiple signing keys in the device does have some advantages.  Nothing says you can't sign the same firmware bundle with multiple keys.  That has the advantage that, presuming that signature verification is done by code in ROM, all of those keys would have to be compromised for someone to be able to overcome the signature verification.

You know, I wonder if Keysight is using a TPM, or something with that kind of capability ...

[Someone]

Fact is Nico is partially right

.. and has been a common pattern with nctnico, making an "issue" out of normal behaviour, where they want different behaviour for some niche use. All the while completely avoiding explaining the obscure niche use case.

The underlying behaviour is trigger interpolation, as in US patent US6753677

Very few cases where people wouldn't want that. Why use only the analog trigger (with its jitter) when the surrounding acquisition data can reduce the total jitter?

[Bud]

It's not just a business decision.  It's a practical one.

This is a matter of semantic. We are talking same thing. We can call it "operational decision".

But shipping the keys themselves in the firmware itself?  If you do that, then you could just surgically replace those keys with your own and bypass the entire signature verification mechanism, no?   

Not until you first replace the current public key in the existing firmware in the scope, in order for the scope to accept the update. This is where practicality of such solution comes into consideration. Yes a few geeks can do it by doing some sophisticated manipulations but this will not be a mainstream type of hack that an average Joe Blow can replicate easily.

[kcbrown]

It's not just a business decision.  It's a practical one.

This is a matter of semantic. We are talking same thing. We can call it "operational decision".

Fair enough.

But shipping the keys themselves in the firmware itself?  If you do that, then you could just surgically replace those keys with your own and bypass the entire signature verification mechanism, no?   

Not until you first replace the current public key in the existing firmware in the scope, in order for the scope to accept the update. This is where practicality of such solution comes into consideration. Yes a few geeks can do it by doing some sophisticated manipulations but this will not be a mainstream type of hack that an average Joe Blow can replicate easily.

Well, this gets back to the claim that someone could hack their scope by directly flashing firmware to the chip, which is essentially what Nico was talking about here.  The only reason for putting bootstrap code in ROM that uses a public signing key that's also in ROM is to prevent that from working.

Keysight apparently does something very similar to what I described in my first message on this subject (here).  Since they don't seem to be using a TPM and (we presume) don't have a signing key in immutable storage, the scope is vulnerable to compromise through a direct firmware flash operation.  But absent compromise of the signing key, or an implementation error, it's vulnerable only to that kind of alteration (or, of course, replacement of the flash chip itself).


In any case, the entire point of all this is to show that manufacturers like Siglent that don't use public key cryptography to prevent modification of their firmware and to prevent unauthorized activation of features are not concerned about their devices being "hacked" (i.e., having people enable features that they didn't pay for or are otherwise not authorized to enable), and this is so because implementation of these measures is straightforward, well-understood, and something the company would have to do only once, and they are very effective, as Keysight's own devices prove (despite the fact that they have made some serious errors in their implementation on some scopes, such as, apparently, allowing boot from an external USB drive without a signature check of the boot image on the drive).  Nobody has a "key generator" or something equivalent for reasonably recent Keysight instruments that I've ever heard of (examples to the contrary welcome).

Yes, you have to implement it correctly and yes, you have to be rigorous about ensuring that there are no ways to bypass the signature checks.  But this is no different from any other mission-critical feature.

[Bud]

In any case, the entire point of all this is to show that manufacturers like Siglent that don't use public key cryptography to prevent modification of their firmware and to prevent unauthorized activation of features are not concerned about their devices being "hacked"

Often times things are much more prosaic. It very well may be that these manufacturers simply do not have the required expertise in that specific field.

[kcbrown]

Often times things are much more prosaic. It very well may be that these manufacturers simply do not have the required expertise in that specific field.

I thought of that.   But every company has a web site these days and every company has to deal with getting a signed presentation key for it, properly manage that key so that it is not compromised, etc., so every company at least has awareness of public key cryptography to some degree.

Moreover, we're talking about companies with engineering groups that have some amount of operating system expertise, among other things.  The likelihood that nobody in the engineering group knows enough about public key cryptography to at least understand that it's capable of doing what we're talking about here, much less be able to do the research necessary to find out such things, is vanishingly small these days, I'd wager, and I'd wager it's been that way for at least the last 10 years.

And finally, all of these T&M manufacturers study each other's approaches to things.  We know this because we've seen that in the various implementations that are in use.  All a company needs to do is understand that a proper cryptographic approach to the issue would make their feature activation mechanism nearly bulletproof, or see that some other company has implemented something like it and that their implementation is nearly bulletproof.

Once you understand the problem you're trying to solve and have some vague idea of what solutions are at least possible, you can hire an engineer with the requisite knowledge to implement the best solution.  So while an inability to perform this kind of implementation might have been understandable as a showstopper 20 years ago or so, that's no longer the case unless the company in question has been living under a rock or something.

[Bud]

Big Clive, a prominent Youtuber, once said - "The Chinese are very good in copying but not very good in understanding how things work". I will leave it at that.

[tv84]

In any case, the entire point of all this is to show that manufacturers like Siglent that don't use public key cryptography to prevent modification of their firmware and to prevent unauthorized activation of features are not concerned about their devices being "hacked" (i.e., having people enable features that they didn't pay for or are otherwise not authorized to enable), and this is so because implementation of these measures is straightforward, well-understood, and something the company would have to do only once, and they are very effective, as Keysight's own devices prove (despite the fact that they have made some serious errors in their implementation on some scopes, such as, apparently, allowing boot from an external USB drive without a signature check of the boot image on the drive).  Nobody has a "key generator" or something equivalent for reasonably recent Keysight instruments that I've ever heard of (examples to the contrary welcome).

Tek, LeCroy and R&S have been using symmetric crypto for many years...

Regarding keygens: You should know that the sharing of that kind of information is inversely proportional to the price of the equipment.

[grg183]

Hello all,

Somehow I got lost in the interesting discussion, but I wonder if anyone has mentioned that it is important to test the unit yourself.

If I were buying something new in this price range, I would ask for a demo. The best device is the one I enjoy working with, nothing is more demotivating than regularly using a device that doesn't fit your workflow.
On the technical side, I firmly believe that A or B brands cannot afford to sell unreliable equipment.

Definitely a good point and I have no intention of forking out $40k+ on any equipment without a demo, just as much as I wouldn't buy a new car without a test-drive.
I guess at this stage I am at a slightly earlier point in the buying process where I am trying to understand what makes most sense.

Since my original post, reading feedback here and thinking further about it I have now answered one of my main questions "should I get a Keysight DSOX6000?" I think that is a definite no at this point. I think there are much better options for a not so much higher price or alternatively the seemingly comparable Rigol 8000 at a much lower price.

[kcbrown]

Tek, LeCroy and R&S have been using symmetric crypto for many years...

Just to be clear, symmetric cryptography is secret-key cryptography, wherein one uses a single key for both encryption and decryption operations.

So I presume you meant public key cryptography, wherein one generates a key pair, where each key in the pair can decrypt the encryption of the other.

In any case, that only reinforces my point.  T&M manufacturers have experience with this.  It's not new to them.  So there's no reason to believe that Siglent and Rigol can't implement such a system if they want.  Ergo, that they haven't is near-proof that they don't want to, which means that they don't care about their equipment being "hackable", and likely prefer it precisely because it gives them an advantage in the hobbyist market.

Regarding keygens: You should know that the sharing of that kind of information is inversely proportional to the price of the equipment.

Of course.  And that shouldn't be a surprise.  The adoption of a piece of equipment by hobbyists is also inversely proportional to its price, and hobbyists are the ones who are most interested in such keygens.  As I noted previously, the most expensive equipment will tend to need the kind of protection I'm talking about the least.

[grg183]

Thought I'd give a follow up on my decision process...

I've decided not to take the offer on the Rigol 8000, I've searched a lot on this scope and cannot find any bad comments about it, everything about it looks great, price is unbeatable and at least on paper it ticks most of my requirements. However I just cannot see this as giving me the confidence that I need in a primary scope, I simply cannot get myself to accept a Rigol for this. If it were a secondary scope I'd definitely go for it though.

Meanwhile I came across the PicoScope 9400 series. I'm not a fan of PC based oscilloscopes for the general use case but this could make a lot of sense for my use case. The PicoScope 9400 can do eye diagram and jitter measurements at very high bandwidths using the SXRTO sampling technique (effectively this bandwidth would future-proof it for my requirements). I do realize that the SXRTO cannot be used for more general oscilloscope uses however I could then cover that requirement by getting a lower-end 1GHz normal sampling oscilloscope such as a WaveSurfer 4000HD, R&S, RTK4A, etc... Budget-wise this would be better since the overall cost would be lower and I can split the purchase of the two scopes over time. At the same time I'd have a 1GHz scope for general purpose use (which I require) and I'd also be able to do eye diagrams on high speed lines with the 9400 with a much higher bandwidth.

Do you think this makes sense?
Any opinions on the 9400?

[2N3055]

Thought I'd give a follow up on my decision process...

I've decided not to take the offer on the Rigol 8000, I've searched a lot on this scope and cannot find any bad comments about it, everything about it looks great, price is unbeatable and at least on paper it ticks most of my requirements. However I just cannot see this as giving me the confidence that I need in a primary scope, I simply cannot get myself to accept a Rigol for this. If it were a secondary scope I'd definitely go for it though.

Meanwhile I came across the PicoScope 9400 series. I'm not a fan of PC based oscilloscopes for the general use case but this could make a lot of sense for my use case. The PicoScope 9400 can do eye diagram and jitter measurements at very high bandwidths using the SXRTO sampling technique (effectively this bandwidth would future-proof it for my requirements). I do realize that the SXRTO cannot be used for more general oscilloscope uses however I could then cover that requirement by getting a lower-end 1GHz normal sampling oscilloscope such as a WaveSurfer 4000HD, R&S, RTK4A, etc... Budget-wise this would be better since the overall cost would be lower and I can split the purchase of the two scopes over time. At the same time I'd have a 1GHz scope for general purpose use (which I require) and I'd also be able to do eye diagrams on high speed lines with the 9400 with a much higher bandwidth.

Do you think this makes sense?
Any opinions on the 9400?

If you can afford that (and it seems that it might be even easier to purchase since you spread the cost over time)  a "sampling" scope and one general purpose scope is a best option. That way you can optimize each for the job.

Picoscope 9400 series is a superb piece of kit and Picotech has good support engineers.. One interesting thing on 9400 is also optional clock recovery outputs.. If you are really interested, you can always contact their pre sales support  and explain your use case.

[hpw]

Thought I'd give a follow up on my decision process...

I've decided not to take the offer on the Rigol 8000, I've searched a lot on this scope and cannot find any bad comments about it, everything about it looks great, price is unbeatable and at least on paper it ticks most of my requirements. However I just cannot see this as giving me the confidence that I need in a primary scope, I simply cannot get myself to accept a Rigol for this. If it were a secondary scope I'd definitely go for it though.

Meanwhile I came across the PicoScope 9400 series. I'm not a fan of PC based oscilloscopes for the general use case but this could make a lot of sense for my use case. The PicoScope 9400 can do eye diagram and jitter measurements at very high bandwidths using the SXRTO sampling technique (effectively this bandwidth would future-proof it for my requirements). I do realize that the SXRTO cannot be used for more general oscilloscope uses however I could then cover that requirement by getting a lower-end 1GHz normal sampling oscilloscope such as a WaveSurfer 4000HD, R&S, RTK4A, etc... Budget-wise this would be better since the overall cost would be lower and I can split the purchase of the two scopes over time. At the same time I'd have a 1GHz scope for general purpose use (which I require) and I'd also be able to do eye diagrams on high speed lines with the 9400 with a much higher bandwidth.

Do you think this makes sense?
Any opinions on the 9400?

My opinion:

12-bit 500 MS/s ADCs: how to go into fs??

±800 mV full-scale input range into 50 Ω: This means no 3.3V digital logic

10 mV/div to 0.25 V/div digital gain ranges: This means no 3.3V digital logic

while was looking at them to, as some figures missing 

or I am wrong