[sdiy] Lockout / DRM chips?

Fri Sep 11 17:16:38 CEST 2026

That is interesting.  Thank-youl

On Fri, Sep 11, 2026 at 2:27 AM rob hukin via Synth-diy <
synth-diy at synth-diy.org> wrote:

> Schematics for all Behringer products are available on their Service
> Portal.
>
> You just need to apply for a login.
>
> rob.
>
> On 11 Sep 2026, at 09:38, David Kantowitz via Synth-diy <
> synth-diy at synth-diy.org> wrote:
>
> 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
>>
> ________________________________________________________
> 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
>
>
> Rob Hukin
> Audiocircus Ltd
>
> +44 7961 883 949 <+44%207961%20883949>
>
>
>
>
>
>
>
> ________________________________________________________
> 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/1c9745a0/attachment.htm>