[sdiy] Lockout / DRM chips?

Fri Sep 11 10:12:02 CEST 2026

Then in that case, my question would be, why insist that the signal
should be analog in the first place? That just seems to be holding you
back. It doesn't seems that you're trying to imagine a railroad, but
more like a less functional car. (Same limitations as a regular car,
but then additional limitations, like a builtin speed limiter or
something as an analogy.) If you're explicitly not backward
compatible, why not send digital signals over a patch cable? Why not
have a backplane with gigabit (or faster) ethernet to route the audio
between modules, and only use the front panel cables as addressing of
where to send the audio? Then you could have polyphony through "one
wire" and a lot of other magic things. If you want to imagine a whole
new ecosystem, make the most of it. And you could also have your
signal encrypted, signed, whatever you want, using standard protocols
like SSL instead of a bodge such as trying to add a side channel
signal for validation.

/Didrik

On Fri, 11 Sept 2026 at 09:38, cheater cheater
<cheater00social at gmail.com> wrote:
>
> It's good that you're asking these questions.
>
> In my case, it wouldn't be "compatible" with existing modules in the
> same way as cars aren't compatible with railroads. They're just a
> different thing.
>
> I think in the general case, of someone else building a hypothetical
> ecosystem, it probably wouldn't be compatible like that either.
>
> The audio should move around in analog form, but there's no reason to
> not have digital on it in some form as well when it's not interfering
> with the analog audio.
>
> On Fri, Sep 11, 2026 at 9:31 AM Didrik Madheden <nitro2k01 at gmail.com> wrote:
> >
> > You still haven't defined the constraints of the question. As in, are
> > these modules that are supposed to transmit an analog audio signal
> > through something like a standard patch cable, then on top of that
> > negotiate some handshake that would allow them to do the lockout? Are
> > these devices additionally supposed to be compatible with existing
> > analog audio gear? These are questions that affect what the solution
> > might look like. As I'm sure you can figure out on your own, if you
> > feed the signal through an analog filter, distortion unit or whatever
> > it is, not only will you probably ruin the authorization signal, but
> > you also remove the ability to send data back through the cable
> > because the module in the middle has high impedance inputs and low
> > impedance outputs, so the signal only goes one direction.
> >
> > And of course, even if you somehow include an authorization signal in
> > the background, that would make all other analog sources incompatible.
> > If I wanted to use an analog oscillator I built on a breadboard, or my
> > own voice singing into a microphone, or a vinyl record from 1972, as a
> > source, I couldn't, as those signal sources obviously don't have the
> > authorization signal. That seems to be the big weakness of the idea:
> > you can't distinguish the "bad guy's" signal output from just any
> > random analog signal. You have not specified what the acceptable
> > tradeoff is in that regard.
> >
> > If this new system is allowed to be completely incompatible with all
> > existing analog gear, you could simply send an encrypted digital
> > signal through the jack, which the other side can decrypt using secret
> > keys only the good guys have, and process the signal. If you plug that
> > signal into anything else, you just get digital noise out because
> > nothing else understands the signal format. This seems impractical.
> > However if this new format entails, not front panel patch cable jacks,
> > but something like a backplane bus, a solution like that might
> > actually be viable. Again, this is not at all defined in the question
> > as asked, and without details like that it's difficult to give
> > practical advice.
> >
> > /Didrik
> >
> > On Fri, 11 Sept 2026 at 06:15, 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