Should I get a Keysight DSOX6004A ?

[kcbrown]

Hard to prove, but the hackings (which appeared out of nowhere and don’t seem to bother them) might have “leaked” from their own marketing departments. In practice, this would allow them to effectively sell at dumping prices while keeping the dumping pricing policy under the radar.

It's pretty easy to show that these companies want their devices to be "hackable".  How do we know?  Because it would be trivial to design them so that the feature activation mechanism is hack-proof.  To wit:

• Use a strong cryptographic private key to sign a message containing the serial number and feature identifier.  Encrypt this signed message with the device's private key.  The result will be the magic file that you put onto a USB stick and tell the device's UI to import for activating the feature in question.
• The device will first decrypt the file with its own public key, and then check the signature with the company's public key.  If the signature verification works then the device will enable the feature specified by the message, as long as the serial number matches.   You could keep the file itself stored on the device and have the device check its file store upon boot to activate the features it finds therein.
• Keep the firmware upgrader in ROM, and cryptographically sign all firmware updates with the company's private key.  The firmware upgrader would fail the firmware update if the bundle fails signature verification with the company's public key.

The security of this mechanism is near-absolute as long as the company's private key, or the encryption algorithm it depends on, is not compromised.  And even if it is, the mechanism is reasonably safe as long as the device's private key remains hidden (the only way to hack it would be to use the company's compromised private key to sign a modified firmware bundle that contains a different public key for the device, one for which you'd have the private key).

[nctnico]

Hard to prove, but the hackings (which appeared out of nowhere and don’t seem to bother them) might have “leaked” from their own marketing departments. In practice, this would allow them to effectively sell at dumping prices while keeping the dumping pricing policy under the radar.

It's pretty easy to show that these companies want their devices to be "hackable".  How do we know?  Because it would be trivial to design them so that the feature activation mechanism is hack-proof.  To wit:

• Use a strong cryptographic private key to sign a message containing the serial number and feature identifier.  Encrypt this signed message with the device's private key.  The result will be the magic file that you put onto a USB stick and tell the device's UI to import for activating the feature in question.
• The device will first decrypt the file with its own public key, and then check the signature with the company's public key.  If the signature verification works then the device will enable the feature specified by the message, as long as the serial number matches.   You could keep the file itself stored on the device and have the device check its file store upon boot to activate the features it finds therein.
• Keep the firmware upgrader in ROM, and cryptographically sign all firmware updates with the company's private key.  The firmware upgrader would fail the firmware update if the bundle fails signature verification with the company's public key.

The security of this mechanism is near-absolute as long as the company's private key, or the encryption algorithm it depends on, is not compromised.  And even if it is, the mechanism is reasonably safe as long as the device's private key remains hidden (the only way to hack it would be to use the company's compromised private key to sign a modified firmware bundle that contains a different public key for the device, one for which you'd have the private key).

It is pretty simple to find the place in software where the key is checked and simply turn the answer in 'yes' regardless of the option is present or not. Obscuring that is a whole other ballgame.

[Bassman59]

So Siglent is simply pragmatic here, i believe. [...] Hacking is hurting them financially, don't doubt that. But not as much as a mad customer.

That’s one way of looking at things.

Another way is that Siglent (or Rigol, for what it matters) are deliberately selling their equipment at dumping prices in an effort to take over the market. In theory, they are not selling dirt-cheap equipment per se (that would be too obvious and could trigger legal procedures in many markets). They are only selling reasonably priced equipment that can be hacked (i.e. upgraded) at no cost.

Hard to prove, but the hackings (which appeared out of nowhere and don’t seem to bother them) might have “leaked” from their own marketing departments. In practice, this would allow them to effectively sell at dumping prices while keeping the dumping pricing policy under the radar.

I’m not complaining (I recently cheerfully “upgraded” some of my own Riglent equipment), I’m just noticing.

So what I don't understand is this.

Rigol and Siglent know that most of their customers buy the base products and "upgrade" them. How many of their customers are actually buying the "upgrades"? Surely even the Big Company customers are always looking to save money, so if the end user engineer with a hard budget cap is looking at oscilloscopes and sees that a Rigol can be bought for $X and "upgraded" at no cost to the same "level of performance" as a Top Brand product that blows the budget, they'll buy the base Rigol.

I don't think R&D groups worry too much about traceability and regular ongoing calibration. They (we, I'm in this category) need performance and features. The Tek DPO3054 on my bench has seen almost daily use since we got it some number of years ago, and it just does its job without much fuss. If it needed service, it would get fixed.

So the point: why do Rigol and Siglent continue the charade of offering "lower-cost" versions of their products knowing that the customers will immediately get a free license key and upgrade it? If they just said, "we are streamlining our product offerings, and no longer offering the license-limited lower tiers," the cash registers would ring ring ring. After all, this wouldn't seem to cost them much money. And then the handful of Big Customers that might balk at the notion of buying the base product and letting the users "upgrade" them would be more likely to buy the products.

What am I missing?

[nctnico]

What am I missing?

Actual numbers to back your assumption.

Before saying that offering upgrades on any piece of test equipment makes no sense because people hack them, you have to gather numbers from a large group of users / test equipment buyers and figure out whether they hacked their equipment or not. And then apply some statistics so get a number that tells you what percentage of test equipment gets hacked. It wouldn't surprise me if that percentage is in the single digits even when it comes to equipment from Rigol & Siglent. Be aware that albeit hacking is very well known on this forum, there still is a massive amount of EEs out there that have never heard of EEVblog and let alone that test equipment is hackable.

[bdunham7]

Actual numbers to back your assumption.

The same issue played out decades ago with Microsoft.  Their products were easy enough to pirate for the hobby-level or developing world user, but western corporations couldn't get away with that.  For Microsoft, every pirated version used did not represent a monetary loss for them, rather it represented a lost sale for their competitors.  Eventually everyone got hooked on Windows and Office and the rest is history.  What we don't know is what proportion of Siglent customers are willing and able to simply hack cheaper versions vs. those that have to do things 'properly'.  And we don't know what sort of deals Siglent is offering their government, educational and corporate customers.

As far as why they play the game the way they do, they didn't invent it--they're just copying the A-brands in that regard.  But it is possible that they noticed a huge surge in sales after the hacks were published...

[Bud]

What am I missing?

That in general companies have support contracts with their vendors and are not interested in this acrobatics.

[kcbrown]

It is pretty simple to find the place in software where the key is checked and simply turn the answer in 'yes' regardless of the option is present or not. Obscuring that is a whole other ballgame.

You don't have to obscure it.  You have to make it difficult or impossible to change it.  I did forget to add one item to my list: have the basic bootstrap in ROM, which will load the firmware image from flash and check its signature using the company's public key.

Even without that, the device is hackable in software only if you flash the firmware directly.  You won't be able to upgrade the firmware without first having compromised the company's private key because the updater will perform a signature check of the firmware update with the public side of that key.

You can't prevent people from hacking the device via hardware changes, of course, so changing the ROM would obviously accomplish that.  That can be mitigated if the ROM contents are in the CPU/SOC directly.   While you can't entirely prevent people from bypassing your code through hardware changes, you can make it expensive enough for them that it isn't worth it.

The point of my message wasn't to illustrate how to make it impossible to hack your way towards enabling features.  It was to illustrate that we know that these companies want their devices to be easily hacked, because they're not taking the rather trivial steps needed to make it difficult enough to do that most wouldn't try (there's a world of difference between a device being "hackable" by way of a simple key generator, a la a number of the Siglent devices, and it being "hackable" by directly flashing the firmware via JTAG or something).

[rsjsouza]

I don't think R&D groups worry too much about traceability and regular ongoing calibration. They (we, I'm in this category) need performance and features. The Tek DPO3054 on my bench has seen almost daily use since we got it some number of years ago, and it just does its job without much fuss. If it needed service, it would get fixed.

Indeed a daily driver for testing and diagnosing might not need to be accurate but, if you are putting a product out of the door or validating a customer's design, it needs to meet a solid standard so the published specifications/parameters can be reproduced at a customer's lab.

[Bassman59]

I don't think R&D groups worry too much about traceability and regular ongoing calibration. They (we, I'm in this category) need performance and features. The Tek DPO3054 on my bench has seen almost daily use since we got it some number of years ago, and it just does its job without much fuss. If it needed service, it would get fixed.

Indeed a daily driver for testing and diagnosing might not need to be accurate but, if you are putting a product out of the door or validating a customer's design, it needs to meet a solid standard so the published specifications/parameters can be reproduced at a customer's lab.

Sure, for those uses traceable/supported equipment is bought and put into service. It would be interesting to see how many oscilloscopes, for example, are used for product validation and how many are used for R&D/debug/repair.

[rsjsouza]

I don't think R&D groups worry too much about traceability and regular ongoing calibration. They (we, I'm in this category) need performance and features. The Tek DPO3054 on my bench has seen almost daily use since we got it some number of years ago, and it just does its job without much fuss. If it needed service, it would get fixed.

Indeed a daily driver for testing and diagnosing might not need to be accurate but, if you are putting a product out of the door or validating a customer's design, it needs to meet a solid standard so the published specifications/parameters can be reproduced at a customer's lab.

Sure, for those uses traceable/supported equipment is bought and put into service. It would be interesting to see how many oscilloscopes, for example, are used for product validation and how many are used for R&D/debug/repair.

I personally have no idea. Just like with DMMs, I imagine the ration between cal/uncal is absurdly slanted towards the latter.

[tv84]

You don't have to obscure it.  You have to make it difficult or impossible to change it.  I did forget to add one item to my list: have the basic bootstrap in ROM, which will load the firmware image from flash and check its signature using the company's public key.

...

The point of my message wasn't to illustrate how to make it impossible to hack your way towards enabling features.  It was to illustrate that we know that these companies want their devices to be easily hacked, because they're not taking the rather trivial steps needed to make it difficult enough to do that most wouldn't try (there's a world of difference between a device being "hackable" by way of a simple key generator, a la a number of the Siglent devices, and it being "hackable" by directly flashing the firmware via JTAG or something).

This is not correct. KS has done a lot of work in trying to make if hard to hack the enablement of features. They have had one of the best methods around.

First, all the points in your first message are currently implemented by KS.

Secondly, the secure boot process that you describe in the 2nd message is the most important thing and you missed that one in the 1st msg. 

The "impossible to change it" is almost impossible as you have access to the device HW but, that, would be definitely a new ballgame .

But, this go against the nature of the very own feature we're trying to protect: enhancement on the field. A secure boot process could introduce problems in the servicing of these units making them harder to service.

It's not like PS/XBOX quantities where, if you have a problem, they replace with a new and get on with it.

[2N3055]

You don't have to obscure it.  You have to make it difficult or impossible to change it.  I did forget to add one item to my list: have the basic bootstrap in ROM, which will load the firmware image from flash and check its signature using the company's public key.

...

The point of my message wasn't to illustrate how to make it impossible to hack your way towards enabling features.  It was to illustrate that we know that these companies want their devices to be easily hacked, because they're not taking the rather trivial steps needed to make it difficult enough to do that most wouldn't try (there's a world of difference between a device being "hackable" by way of a simple key generator, a la a number of the Siglent devices, and it being "hackable" by directly flashing the firmware via JTAG or something).

This is not correct. KS has done a lot of work in trying to make if hard to hack the enablement of features. They have had one of the best methods around.

First, all the points in your first message are currently implemented by KS.

Secondly, the secure boot process that you describe in the 2nd message is the most important thing and you missed that one in the 1st msg. 

The "impossible to change it" is almost impossible as you have access to the device HW but, that, would be definitely a new ballgame .

But, this go against the nature of the very own feature we're trying to protect: enhancement on the field. A secure boot process could introduce problems in the servicing of these units making them harder to service.

It's not like PS/XBOX quantities where, if you have a problem, they replace with a new and get on with it.

This...

People who are not in security industry at all (no knowledge at all) and people who are professionally in security industry have same problem in common: they disregard how expensive security is.
First one think it's cheap so it should be done to the fullest, because they think it's free and have no negatives, so why not.
People in security industry OTOH, have no regards or even perception of limits where security is getting to expensive, and too damn taxing to people and and how it interferes with actual work trying to be done here. They are aware of the price but don't care. Somebody else is paying. As long as they follow the latest trends that don't have connection to reality anymore..

One company I consult for, just introduced 15 CHARACTER passwords (at least one number, capital letter, letter and special character) for login to Windows Domain.

They think they are more secure now. There cannot be any hacker attacks on this, right? From my real life experience, they just plummeted security to efin zero.

First thing people did was to write the passwords down on PostIT note papers and stick it to the monitor.
Because , 95% of people working in their offices cannot be expected to remember that shit.
Not to mention  they had like 1000%  increase in locked accounts, because when people want to log in to windows in a hurry, then typing 15 characters blindly (yeah no peeking, that is insecure, someone could read it from the screen. If your PostIT note has bad handwriting).
Support is overwhelmed.People are livid. And security is zero. Passwords are all over the place, stuck to the monitors.

Security "Experts" don't care. They read it in some magazine that is a modern thing to do nowadays or whatever.
It is not that they designed retarded, unrealistic security solution.
No, problem is them people are not following rules. 

WTF happened to risk analysis? What is the cost/benefit here, security wise? How is that good security?

Same thing with scopes. Creating a secure WORKFLOW for the whole scope company, costs a LOT of money and drops productivity. It is not as if: you zip it and it's secure.

It has to be secured from beginning to the end. You can have everything secured, if someone leaks keys, bye bye.. So suddenly, you're not scope company anymore. You're running a military facility, with pat  downs to see if someone tries to bring in forbidden surveillance equipment. No phones or communication devices on the premises. Partitioned offices with security clearances. Regulated paths to bathrooms and cafeteria. Security staff that supervises implementation. SIGINT monitors for 24/7 monitoring of illicit communications equipment. Human resources doing background checks.... Down the rabbit hole.
And customer pays for it...

Not doing same type of security like Keysight or R&S , by Siglent and Rigol, is also part of savings passed on to customers.

So yeah, they made the right decision... If few hobby users hack the scope, that is not important.
Also hackability has dick squat influence to purchasing decisions of professional users. Companies perform regular inventories and actively monitor all IT equipment to make sure nobody installed illegal software and licenses to any equipment. They think the same about this too..
And why would you even consider that: Keysight Full Bundle for  3000T series is like 2500€ +VAT.  Siglent SDS2350X+ can be had for that money. With most protocols included.
Companies think like that. Even when you pay full price, Siglent equipment is good deal compared...

[rsjsouza]

WTF happened to risk analysis? What is the cost/benefit here, security wise? How is that good security?

Indeed. there is always a balance of insecurity between the blatantly insecurity (free text passwords that give in to "1234" combinations) and the übersecure systems you describe.

(such statements could easily be adapted to the entire government decision making process throughout 2020/2021...)

[grg183]

To have the Wavepro HD to have the same features as the Rigol 8000 this is going to be £54K plus the logic probe is quite a bit and the 500Mpts of memory they have another of you buy model 'x' then you will receive either a BW upgrade or Mem upgrade to 1GPTs to 2, but that’s costly.

That pricing is very much in line with the WaveProHD quote that I have, and of course I need to factor in the price of any possible future licenses/ probes, etc. It is certianly not an insignificant amount, expecially also because this year I have already spent a good deal in a major refurbishing of my lab - reason for which I had to postpone this scope purchase to next year. However I know that the WaveProHD would be a tool that would satify my requirements for the forseeable future without any compromises. On the other hand, there is currently an offer on the Rigol MSO8204 for Eur8990 with full options bundle which I am highly tempted to grab. Realistically and judging also from your valuable feedback and other sources I am now more confident that the Rigol would satify my immediate needs. At that price (practically equivalent to a good WaveProHD probe), I am seriously considering getting the Rigol, use it as far as it can take me and then reconsider the purchase of a higher-end scope in the future.

I looked at the R&S RTO6 too, it is very interesting and more affordable but the 8-bit ADC, apparently higher noise floor, etc... are not convincing me.

I still need to look into the HDO8000

Would it be my primary scope if we didn't need the fancy low noise and speed plus monster apps. It may well be.

Its still on my bench 18 months down the line and sitting with some big hitters but it feels safe and secure 

These comments sound very encouraging, if after 18 months you have not found anything worth complaining about I guess it is mature enough for a professional environment.

If you went down this route you could also purchase a great Keithley 6.5 or 7.5 digit DMM as well plus a a couple of misig new current probes as well.

Actually I already have a Keithley DMM6500 and also a few nice Keysight current probes.

[Sighound36]

Some good thoughts there grg183

I also have an MDA8000 HD, you can run SDA III apps on this on this one as well and they do have a BW limit of 2Ghz.
We are involved in a lot of 3 phase work, hence why we have oe of this scopes as well plu 8 channels @10G/s all the time unlike Tek 

Do also tae in to consideration, if you purchase moe of the apps @ time of scope purchase leCroy tened to look favorably on this, after the inital purchase then you may find its little or zero discount, so buy all of the 'prefered and esstenail more costiliers apps then.

The Wavepro has aroud 20 apps. the MDA8000HD has around four, the HDO6000 has 22 apps which are used almost daily.

According to our Lecoy rep my nickname is probe-miester  we have seventeen of the genuine Lecroy probes, especially the RP-4030 rail probes four of these, three HVDP, five current probes, three passive probes and three active probes 

The Rigol 8000 has All of the options available, I do take it out in the field as well, have five probes for this unit including  nice pcio connect 4Ghz passive unit and the neat TPA189 30 amp 1m/a resolution current probe.

We also have a DMM650 & 7510 units.

Good luck with your decision, if you wish to know anything specific just pm me.

Sighound36

[NEDM64]

I'm exploring the options for a 1GHz+ bandwidth oscilloscope for professional use (I am an electronics engineer and run a small professional electronics design business). I'll probably not be buying this until next year but I'm starting to evaluate the options.

Some main features that I am looking for are:
- 1GHz bandwidth, preferably upgradable to 2.5Ghz or more.
- 4 analog channels, digital channels a plus but not necessary
- jitter analysis
- eye diagrams
The main need for this oscilloscope is for high speed signal analysis. I have been working on high speed designs already but this is becoming increasingly common and demanding so I am looking to upgrade my equipment.

I am a bit of a Keysight fan, I own a Keysight MSOX3024T oscilloscope and a Keysight FieldFox N9923A VNA and have always been happy with their quality and support.
I also understand the value and importance of quality tools, I need my tools to be reliable and accurate, every time. I don't have time to waste troubleshooting problems with tools and or worse being misled by an inaccurate measurement.
I also have a Keysight N2790A high voltage differential probe and a Keysight N2893A current probe, which have a Keysight specific active interface. These probes alone cost around $6k so I would ideally like to be able to used them with the new scope too.
Having a 'brand name' oscilloscope is also beneficial for when I need to include it in reports or screenshots sent to clients, but it is not the deciding factor.
Unfortunately being a small business puts me in a sort of gray zone between markets, since I have the needs for a high end scope for professional use but while I can afford some of the brand names, I don't have money to throw away like big companies do.

By the way, I'm sure there are great deals to be made with used equipment but I am generally not interested in used equipment, no matter how good of a deal it is (well I'll take it if it is practically free :-) ), except perhaps for 'Keysight Premium Used' but even that only if I really cannot justify the price of new hardware.

So naturally my first choice would be the Keysight DSOX6004A. I could get the 1GHz version and then upgrade it as needed over the next few years. That would be perfectly reasonable budget-wise.

I was considering the RTA-COM4 offer from R&S too but it is not upgradable past 1GHz and afaik doesn't do jitter analysis or eye diagrams, so while I'm sure it is an excellent instrument I think it would be limiting me in future.

In general I don't like Tektronix gear so much but if it makes sense I will consider it.

The Lecroy WavePro 254HD would probably be the best choice from a technical and feature standpoint. Budget-wise I can afford it and probably even justify it but for the current size of my business it is still a lot of money. I am not very familiar with Lecroy gear but it seems to be a better bang per buck compared to the Keysight DSOX6004A.

About the DSOX6004A, my concern, is that the DSOX6004A is based on a now fairly old MegaZoom IV asic and still only has 4Mpt memory (I know the benefits of segmented memory but still..). Meanwhile I am seeing that in these past years the 'cheap' brands have come a very long way. I'm looking at the Rigol MSO8204 for example and I cannot help but think whether I should really spend all that money on the DSOX6004A. On paper the Rigol MSO8204 seems to be a good fit, with loads of memory and at a fraction of the price. It could potentially make sense to get an MSO8204 now to cover my current needs and then look back into something better in a few years time. I didn't hesitate when I bought the Keysight MSOX3024T 5 years ago but it was a smaller investment and the cheaper alternatives were nowhere close to it's specs back then.

So I guess my main questions for you are:
- Do you think that in 2021/22 the Keysight DSOX6004A is still a good investment considering the old asic and limited memory?
- What is your opinion on the Rigol MSO8204? Am I crazy to even consider this for professional use? I've looked around for reviews of the MSO8000 series but the only videos I found are from Rigol and even on this forum there are only a few sporadic comments about it. I'd be interested to hear from anyone using the MSO8000 in a professional lab setting.
- Excluding Keysight, what oscilloscope would you suggest for my use case?

For these questions I am more concerned about having quality equipment for professional use rather than saving money, but at the same time I'd like to spend the money wisely.

Thanks

No, they will give you the middle finger if it breaks outside the warranty and tell you to pay for their "keysight care" BS.

[kcbrown]

This is not correct. KS has done a lot of work in trying to make if hard to hack the enablement of features. They have had one of the best methods around.

First, all the points in your first message are currently implemented by KS.

Yes.  And have you noticed that nobody is able to enable features on KS equipment without going to substantial effort, including hardware modification of the device?

My argument isn't that full prevention of feature enablement is possible.  My argument is that the fact that manufacturers such as Siglent don't go to the rather minimal effort to attempt such prevention is proof that they want their devices to be, or at least don't care if their devices are, easily "hackable".

Secondly, the secure boot process that you describe in the 2nd message is the most important thing and you missed that one in the 1st msg. 

Yes, well, it took me all of about 30 seconds to come up with the items in the first message (a bit longer to actually type them in), so that what I showed wasn't entirely comprehensive is perhaps forgivable.      And in any case, the secure boot process is necessary only if you're trying to prevent someone from being able to flash the firmware directly on the board.  The first set of items is still sufficient to prevent modification by way of a "key generator" or something, presuming that the company's private signing key remains uncompromised.

The "impossible to change it" is almost impossible as you have access to the device HW but, that, would be definitely a new ballgame .

Certainly.

But, this go against the nature of the very own feature we're trying to protect: enhancement on the field. A secure boot process could introduce problems in the servicing of these units making them harder to service.

All it means is that the firmware image you supply has to be properly signed and free of corruption.  Interestingly, the signature also gets you integrity checking for free, which for these instruments is highly desirable.  If your firmware upgrader is also in ROM, which it clearly should be, then the only way the device would be harder to service would be if the ROM itself were bad, in which case you're now looking at a hardware repair.  But that's no different than any other hardware malfunction, and if you're looking at a hardware repair then as a practical matter you're looking at board replacement or unit replacement anyway.

It's not like PS/XBOX quantities where, if you have a problem, they replace with a new and get on with it.

Um, well, with many of these instruments, particularly the low-end hobbyist models, that's exactly what they do.  And, honestly, that shouldn't be much of a surprise.  Replacing the unit means that the customer is back on his feet faster, and gives the company as much time as it wants to repair the original unit, should it decide that it's worth the trouble.

And we're really talking about the low-end hobbyist models in the first place (seeing how the question is about whether or not the manufacturers want their devices to be "hackable", and the people most inclined to do that are hobbyists).


Ironically, the upper-end models are the ones that need the least protection.  They're so expensive that few hobbyists would buy them, which leaves companies and other professional-level entities that have to keep everything above board because for them, the after-sales service is even more important.

[hpw]

So would one man now trust and gets into heaviest trouble as getting this nice used 6004 for $22,233.00 https://www.ebay.com/itm/Keysight-Used-MSOX6004A-Oscilloscope-4-GHz-20GS-s-4-Channel-w-app-bundle-/194282706085?hash=item2d3c26d4a5#shpCntId

just for 30 days warranty included many SW options and without any probes 

Hp

[nctnico]

So would one man now trust and gets into heaviest trouble as getting this nice used 6004 for $22,233.00 https://www.ebay.com/itm/Keysight-Used-MSOX6004A-Oscilloscope-4-GHz-20GS-s-4-Channel-w-app-bundle-/194282706085?hash=item2d3c26d4a5#shpCntId

just for 30 days warranty included many SW options and without any probes 

Hp

The idea is that you buy extra service so it gets fixed if it breaks. Probably you can negotiate a bit to have it included in the price or a discount.

[2N3055]

This is not correct. KS has done a lot of work in trying to make if hard to hack the enablement of features. They have had one of the best methods around.

First, all the points in your first message are currently implemented by KS.

Yes.  And have you noticed that nobody is able to enable features on KS equipment without going to substantial effort, including hardware modification of the device?

My argument isn't that full prevention of feature enablement is possible.  My argument is that the fact that manufacturers such as Siglent don't go to the rather minimal effort to attempt such prevention is proof that they want their devices to be, or at least don't care if their devices are, easily "hackable".

Single hardware revision simplifies complete process immensely.  You basically make a batch of 1000 all the same scopes and then you can dynamically decide which ones are which. Let market decide. Big plus. Same for spare parts... Same for fixes, upgrades..

Your argument is wrong.

Keysight made 3 separate oscilloscopes for 3000T series because they are asses, because the cost of "protection from customers" is paid by those very customers by charging them higher prices.

What you extol as a virtue is asshollery... If they had to pay for it from their already small profits, they would switch to single motherboard per model like everybody else..
There is nothing positive or virtuous in their practice, only disregard for anything but their interest and yet  Siglents and Rigols are somehow villains..
 

Few years ago I bought a fully loaded brand new MSOX3104T for a fraction of price, because they make it in batches, and if they don't sell (and they don't as well as lesser models because they cost too much) at some point they are selling them off at ridiculous prices to get rid of the stock. It they were all the same model, they could have had reconfigured them.

And yes, the new Keysight EXR and MXR is completely software configurable. Even if you buy 500MHz 4 ch scope, you get full 8 channels 2.5 GHz (6GHz on MXR) scope, signal gen, MSO, everything, software locked to less channels and bandwidth.
So on old models with cheaper components they were doing 3 hardware variants. Now on new expensive scopes (I would think that saving 4 16GS/s and 4 6GHz analog front ends would save a lot of money.)
only one hardware variant per model. Go figure.. Maybe it still make some kind of sense for them to do it that way for all the benefits they get.

[grg183]

My argument is that the fact that manufacturers such as Siglent don't go to the rather minimal effort to attempt such prevention is proof that they want their devices to be, or at least don't care if their devices are, easily "hackable".

I don't think it is so much that they don't care or want them to be hackable, it is more likely a simple matter that they are not willing to spend more than they need to in development costs on something that is not a marketable feature. When you sell a product with soft-license enabled hardware features like this, the amount of savings in R&D, prototyping, testing, validation, part sourcing, production, production testing, product stocking, distribution, warranty replacements, etc... are huge. Just think of the simplified logistics of having to only build and ship one version instead of 4/5. The price that they sell the lower-end model at needs to cover the cost of the higher-end hardware that they are giving you plus a good profit margin. Especially for someone like Siglent/Rigol who is targeting the budget conscious market, they know that their biggest sales will be on lower-end models, so the profit margin is already adjusted for that. If they have to spend more money in development, testing, debugging, support, and possibly higher cost parts just to secure the license further they would just be eating away from their own profit margin and most of their sales would still be on the lower-end model. Keysight and the others target the less budget-conscious users and their profit margins are high enough to justify the extra costs for license protection, they also know that many of their sales will be on the higher-end models so the effort is justified. In product design everything is done based on a target cost (both in terms of BOM and also development costs), if the development effort to add the security does not fit in that cost it is simply not done. That development time is better justified on marketable features for new products.

[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.

[kcbrown]

Single hardware revision simplifies complete process immensely.  You basically make a batch of 1000 all the same scopes and then you can dynamically decide which ones are which. Let market decide. Big plus. Same for spare parts... Same for fixes, upgrades..

Your argument is wrong.

Sorry, I apparently wasn't entirely clear when I said "nobody is able to enable features on KS equipment without going to substantial effort".   I was referring to people enabling features that they weren't authorized to enable.  I thought the overall context made that clear, but apparently not.  No worries.

I'm not arguing that the hardware needs to be different across models.  I'm arguing that if the company wants to prevent people from "hacking" the firmware, the company can do so through the firmware itself (which, of course, includes a moderate amount of ROM).

Hackable is not the same as software configurable.   The former means that someone who is not authorized to change the configuration on the device, or not entitled to enable a given feature of it, is capable of doing so anyway without going to the trouble to make any hardware changes.

What I spoke of are firmware-level operations.  The upgrader is a piece of firmware.  The boot loader is a piece of firmware.  Those two pieces should be in read-only memory (i.e., fixed at manufacture time) and should enforce signature verification of the firmware stored in flash (i.e., the firmware that actually provides the functionality of the device) if the company wants to ensure that hacking cannot occur except through hardware changes (here, at a minimum, it would mean replacing the ROM, and if the ROM is embedded in the processor then it would require a processor change).

[kcbrown]

My argument is that the fact that manufacturers such as Siglent don't go to the rather minimal effort to attempt such prevention is proof that they want their devices to be, or at least don't care if their devices are, easily "hackable".

I don't think it is so much that they don't care or want them to be hackable, it is more likely a simple matter that they are not willing to spend more than they need to in development costs on something that is not a marketable feature. When you sell a product with soft-license enabled hardware features like this, the amount of savings in R&D, prototyping, testing, validation, part sourcing, production, production testing, product stocking, distribution, warranty replacements, etc... are huge.

And that would be the case even if the manufacturers implemented firmware signature verification and feature descriptor signature verification.


It seems clear that there's confusion about what I'm saying.  It looks like a primer on public key cryptography as relates to signatures is in order.

In public key cryptography, keys are actually key pairs.  When you generate a key pair, you generate a public key and a private key.  The intent is that the public key can be published while the private key is a closely guarded secret.  As a general rule, the public key is used for signature verification and to encrypt data that can only be decrypted by the private key.  The private key is used to sign data and to decrypt data that was encrypted using the public key.   Data which is encrypted and/or signed can be anything.

When you sign a piece of data, you generate a cryptographic hash of the data and then encrypt that hash using the private key.  That is the signature.  Signature verification happens by hashing the same data using the same algorithm and then comparing what you get against the value you get when you decrypt the encrypted hash with the public key.  When the two match, you have verification.

So if you're the manufacturer and you want to prevent someone from enabling features on their device unless authorized by you to do so, then you can accomplish that by ensuring that the only way they can enable a feature on their device is through execution of firmware code that you wrote that checks for the presence of the appropriately-signed magic token (said magic token can be as simple as a single line of text that has the feature identifier and the device's serial number) that you would supply to them, and refuses to enable the feature unless both the signature verification of the token and the validation of the token (in particular, verification that the serial number in the token matches the serial number of the device) succeeds.  Since the signature on the token was generated by your private key, i.e. a very closely guarded secret, and because the signature and hashing algorithms used are cryptographically strong, the difficulty of fooling the feature checking mechanism would be astronomically high.

That leaves only protection of the checking mechanism itself.  And the same techniques can be used for that as well.  To wit, you cryptographically sign the firmware, and embed in ROM a bootstrapper that checks the firmware's signature and refuses to load it if the signature check fails.  Because the signature check involves cryptographically hashing the firmware image, this signature check is also an integrity check.   Of course, because you have to account for the possibility of corrupt firmware, you'd need to supply a firmware upgrader in ROM as well.

So the ROM would need to have four things in it:

• The first stage of the bootstrap loader (enough to check the signature on the firmware in flash and then begin execution of it if the check passes)
• The firmware upgrader
• The device's serial number
• The company's public key

That's it.  Everything else can be in flash-held firmware.

The thing here is that you only need to do the development of this system once.  Once you've developed it, you can use it universally across your entire product range and guarantee that if someone attempts to hack their device to enable a feature that you didn't authorize them to have, they can succeed only by replacing the ROM on their device.  Which is a hardware change.


So, to summarize, we know that companies like Siglent at a minimum don't care about their devices being feature-upgradeable by people who they didn't sell the feature to because they didn't go to what amounts to a tiny amount of R&D (most certainly when amortized over all devices) to implement a system like the above to prevent it.  This stuff isn't hard, all of the heavy lifting was done long ago, so it just requires someone who knows what he's doing -- which is true of every properly functioning feature in every device.

[Bud]

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).
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.
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.
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.