[sdiy] Lockout / DRM chips?

Fri Sep 11 06:19:34 CEST 2026

Would this example approach satisfy your needs:  every output is mixed with
wide-band PRNG noise and only "in family" modules have the algorithm to
filter that noise from their inputs.

On Thu, Sep 10, 2026 at 9:09 PM cheater cheater <cheater00social at gmail.com>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20260910/a4430224/attachment.htm>