[sdiy] Lockout / DRM chips?

Fri Sep 11 10:38:31 CEST 2026

It does seem a bit odd.  Personally my view is folks would be better off
working *with* Behringer.
Imagine if B has open sourced schematics & s/w for their Brains board.
I really doubt B gives half a toss about the software: they make money
selling boards.
Even with all the schematics, I doubt people will be able to sell the
module more cheaply than B.
B would simply sell more boards ... exactly what B wants!

Use the few thousand hours it would take to build a solid DRM system to
convince B to be a better partner to the SDIY community.

On Fri, Sep 11, 2026 at 12:40 AM Márton Bertók via Synth-diy <
synth-diy at synth-diy.org> wrote:

> My stuff is open source, feel free to clone them. Cloning is an essential
> part of SDIY. You’re advocating killing DIY with DRM on the SDIY mailing
> list, which sounds bonkers to me.
>
> > On 11 Sep 2026, at 09:29, cheater cheater <cheater00social at gmail.com>
> wrote:
> > Wait for behringer to clone your hardware and you'll sing a different
> tune
> >
> > On Fri, Sep 11, 2026 at 9:25 AM Márton Bertók <marton.bertok at me.com>
> wrote:
> >>
> >> This sounds worse than anything Behringer ever pulled.
> >>
> >>> On 11 Sep 2026, at 06:13, cheater cheater via Synth-diy <
> synth-diy at synth-diy.org> wrote:
> >>> 
> >>>> Honestly, it's a bit hard to point you in the right direction without
> understanding what you actually want to do.
> >>> Ultimately the goal is as follows.
> >>> Situation: A new physical format, let's say for modular synthesizers
> >>> or audio effects, is created.
> >>> Problem: how to lock out a specific manufacturer that clones devices
> >>> created by others, so they don't shit up this format as well?
> >>> Solution: some form of hardware authorization and authentication
> >>> Purpose of the discussion: The first part can be something myself and
> >>> some others are planning, or it could be something that a completely
> >>> different group of people are doing and they could use what's been
> >>> learned here as basis for safeguarding their business from parasitical
> >>> manufacturers
> >>>> On Thu, Sep 10, 2026 at 10:02 PM David Kantowitz <
> dkantowitz at gmail.com> wrote:
> >>>> Not really. Search for "secure microcontroller" at the NXP website.
> The detailed manuals (at least for NXP) usually require an NDA w/ NXP, but
> a 2-page summary sales sheet should be available.
> >>>> A lot of microcontrollers (not just NXP) have features like: 'secure
> boot', 'secure element', 'secure memory', 'trusted module', 'trusted
> execution', etc.  ARM has TrustZone that a lot of manufacturers use.  Some
> combination of those features could do what you want.
> >>>> Honestly, it's a bit hard to point you in the right direction without
> understanding what you actually want to do.   ... and based on my earlier
> emails, what you described as wanting to do doesn't really make sense to me
> in a commercial context.  There are significant costs involved in building
> even vaguely secure hardware.  An example of the stupid shit that happens
> ... units were keyed at Key Injection Facility, then shipped to the user
> site, units started to arrive in the tamper state with no keys .. queue 6
> month parade of units back and forth ... eventually we figure out that a
> software bug wasn't putting the cpu into a low enough sleep state and the
> supercap keeping the keys alive was drained in transit.  I can't even bear
> to describe how stupid the spares situation became.
> >>>>> On Thu, Sep 10, 2026 at 11:51 AM cheater cheater <
> cheater00social at gmail.com> wrote:
> >>>>> Thanks, David. That's some good info. Can you point to some recent
> >>>>> devices that are available on the market?
> >>>>> On Thu, Sep 10, 2026 at 7:22 PM David Kantowitz <
> dkantowitz at gmail.com> wrote:
> >>>>>> BOM cost was single digit USD.  Essentially it was a way to audit
> licensing fees through an electronic component based supply chain.
> >>>>>> What you're describing are key rolling and key injection.  You can
> look at current practices for payment terminals, but honestly those are
> made-by-committee unions of the individual company's own practices.
> >>>>>> We used two basic approaches to secure the cryptographic root:
> >>>>>> 1. 'Base' key injection key that's used only to load
> site-deployment keys.  Those keys were secured by obscurity.
> "Steganographic methodology" when we wanted to sound like experts.
> >>>>>> 2. Shipping units to a secure key injection facility.  Use tamper
> evident bags when you want a fancy audit trail.
> >>>>>> Site keys are stored in something physically tamper-proof.  As a
> simple example (ie. what was done 20 years ago):
> >>>>>> - make a PCB sandwich.  all components on inside, no traces on
> outside of PCB.  single power & serial port on outside. a plastic ring goes
> around the edge. bolot he sandwich together.
> >>>>>> - electrical connection between the two boards via pin headers
> >>>>>> - put key in static RAM (not flash, not DRAM)
> >>>>>> - SRAM on board A, battery on board B
> >>>>>> If someone opens the sandwich and the site keys lose power.  Back
> to (1) or (2) above to restore site keys.
> >>>>>> Despite having microcontrollers with secure memory, much more
> physically complicated versions of the sandwich are still used today:
> >>>>>> (A) Detect the tamper.  (B) Destroy the keys.  (C) Restore the keys.
> >>>>>> Separately, everyone also builds in some method for key-rolling
> into their systems.  This handles the scenario you described: you believe
> the keys were actually stolen with malicious intent.  Personally, I've gone
> through customer witnessed testing of the key rolling, I've never seen a
> live system do a key roll.  It was simply too risky.  Instead we would
> maintain blacklists of cards & equipment.  This requires a system that is
> frequently online.
> >>>>>> On Thu, Sep 10, 2026 at 9:20 AM cheater cheater <
> cheater00social at gmail.com> wrote:
> >>>>>>> I agree that the DRM is just one component of an otherwise healthy
> >>>>>>> business strategy.
> >>>>>>> Do you remember how much roughly the NXP chips added to your BOM?
> >>>>>>>> This seems to be the arc of most cryptographically enabled DRM.
> >>>>>>> I agree. I know about power monitoring, power glitching, and
> various
> >>>>>>> other hardware attacks.
> >>>>>>> One thing that I'm curious about is things like updating
> encryption,
> >>>>>>> in order to be able to repudiate compromised keys, eg from
> >>>>>>> manufacturers who have decided to start leaking them to companies
> who
> >>>>>>> shouldn't have them. This would at least require some sort of
> secure
> >>>>>>> vault with a machine of some sort inside, probably a VM.
> >>>>>>> Cheers,
> >>>>>>> D
> >>>>>>> On Thu, Sep 10, 2026 at 6:09 PM David Kantowitz <
> dkantowitz at gmail.com> wrote:
> >>>>>>>> The closest "on topic" experiences I have are with the
> contactless payment (and ID) cards.
> >>>>>>>> To read/write Mifare cards, we had to include the Philips (now
> NXP) reader chip in our equipment: even though our own DSP/FPGA generated
> the RF modulation signals and we had our own implementation of the on-air
> data protocol stack.
> >>>>>>>> All the Philips chip contained was their proprietary
> shared-secret encryption algorithm.
> >>>>>>>> Two things happened over time:
> >>>>>>>> 1. Researchers reverse engineered/discovered and published the
> exact proprietary cryptographic algorithm.
> >>>>>>>> 2. Various key recovery techniques were possible through either
> defects in the protocol implementation or techniques like power monitoring
> (which you can also think of as an implementation defect).
> >>>>>>>> This seems to be the arc of most cryptographically enabled DRM.
> >>>>>>>> The Philips chips were generally easy to use and the integration
> cost was more a one-time expense.  Still they added to the BOM cost.
> >>>>>>>> Even after the system was broken we continued to use them: it was
> the easiest way to vouch to our customers that our equipment was compatible
> with Mifare cards.  That compatibility was necessary because, by then, out
> customers had money sunk (ie. millions) into cards.
> >>>>>>>> Briefly off topic: that 10+ year experience taught me that
> DRM-like capabilities are small (nearly irrelevant) technical components in
> a broader commercial strategy ; figure out the strategy first and then use
> DRM as a temporary stepping stone in that strategy.
> >>>>>>>> On Thu, Sep 10, 2026 at 12:41 AM cheater cheater via Synth-diy <
> synth-diy at synth-diy.org> wrote:
> >>>>>>>>> David, Mike,
> >>>>>>>>> Please start a separate thread, this isn't what this thread is
> about.
> >>>>>>>>> Thanks.
> >>>>>>>>> On Thu, Sep 10, 2026 at 8:58 AM David Huss via Synth-diy
> >>>>>>>>> <synth-diy at synth-diy.org> wrote:
> >>>>>>>>>> The idea to do some sort of multichannel modular via digital
> cables is not exactly new and not exactly something that isn't obvious.
> >>>>>>>>>> Technically such a thing is already done with ADAT/Toslink
> optical cables and many audio interfaces use it to allow users to add more
> I/O channels.
> >>>>>>>>>> So the main obvious question is why we haven't seen something
> like this widely used in the modular world?
> >>>>>>>>>> To me the answer is that the simplicity of the concept is
> unbeatable: Everything is just a voltage versus time, one signal per cable,
> what you see is what you get. All while being reliable, cheap to implement,
> cables are cheap, clocking is not an issue, it is conceptually clear, etc.
> >>>>>>>>>> The two useful applications of multi-channel cables I see are:
> (1) polyphonic modules where patching up 4+ cables is annoying and takes up
> valuable panel space and (2) breakout boxes for multichannel connections
> between racks (e.g. via Ethernet).
> >>>>>>>>>> Of course I could envision cool systems with multi-channel
> cables, but I am not sure it is really worth the extra complexity to make
> them digital. By that point one can ask, why not just run everything on a
> computer and make a patch-cable controller panel that just reads out the
> patch connections, knob positions etc and controls a big virtual modular.
> >>>>>>>>>> On September 9, 2026 11:44:34 PM UTC, Gordonjcp <
> gordonjcp at gjcp.net> wrote:
> >>>>>>>>>>> On Wed, Sep 09, 2026 at 07:31:21PM +0200, cheater cheater via
> Synth-diy wrote:
> >>>>>>>>>>>> So, there's good news and bad news. The bad news is that I
> can't go
> >>>>>>>>>>>> into specifics, but there are good reasons to expect a new
> modular
> >>>>>>>>>>>> format showing up sometime in the not extremely distant
> future.
> >>>>>>>>>>> Good luck with that.
> >>>>>>>>>>> How did you get one with your polyphonic modular idea with 24
> channels of 24-bit 192kHz CV on a single 3.5mm jack?
> >>>>>>>>>> ________________________________________________________
> >>>>>>>>>> This is the Synth-diy mailing list
> >>>>>>>>>> Submit email to: Synth-diy at synth-diy.org
> >>>>>>>>>> View archive at: https://synth-diy.org/pipermail/synth-diy/
> >>>>>>>>>> Check your settings at:
> https://synth-diy.org/mailman/listinfo/synth-diy
> >>>>>>>>>> Selling or trading? Use marketplace at synth-diy.org
> >>>>>>>>> ________________________________________________________
> >>>>>>>>> This is the Synth-diy mailing list
> >>>>>>>>> Submit email to: Synth-diy at synth-diy.org
> >>>>>>>>> View archive at: https://synth-diy.org/pipermail/synth-diy/
> >>>>>>>>> Check your settings at:
> https://synth-diy.org/mailman/listinfo/synth-diy
> >>>>>>>>> Selling or trading? Use marketplace at synth-diy.org
> >>> ________________________________________________________
> >>> This is the Synth-diy mailing list
> >>> Submit email to: Synth-diy at synth-diy.org
> >>> View archive at: https://synth-diy.org/pipermail/synth-diy/
> >>> Check your settings at:
> https://synth-diy.org/mailman/listinfo/synth-diy
> >>> Selling or trading? Use marketplace at synth-diy.org
>
> ________________________________________________________
> This is the Synth-diy mailing list
> Submit email to: Synth-diy at synth-diy.org
> View archive at: https://synth-diy.org/pipermail/synth-diy/
> Check your settings at: https://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20260911/970f6405/attachment.htm>