Nobody knows what happened within the MMC Association in 1998.
In 1999, some members from the MMC Association decided to split and create SD Association.
But nobody seems to exactly know why.
MMC's origins are non-trivial to source. At the time of writing, the Wikipedia article on the MultiMediaCard cites a Tom's Hardware blogpost, which briefly mentions that MMC was "codeveloped by SanDisk and Infineon Technologies AG (formerly Siemens AG) in November 1997". Other citations in said article are equally as poor: the sources also include a makeuseof article, and the citation is about... low-level hardware quirks. Hence, I'm not taking anything written there at face value.
Digging for actual sources lead me to the MMC Association's news page (archived, 1998), which itself linked to a press release by SanDisk. The interesting parts are:
Ericsson, Motorola, Nokia, QUALCOMM and Siemens Private Communication Systems Announce Support For MMC PALO ALTO, CA, Nov. 5, 1997 -- SanDisk Corporation (NASDAQ:SNDK) and Siemens AG today introduced the MultiMediaCard (MMC), the world's smallest solid state storage device.The exact course of events during development is likely lost to time, but we can at least be sure that Siemens started it, while SanDisk and the rest joined later. This release also documents some interesting historical oddities:
Originally conceived by Siemens, the MultiMediaCard has been jointly developed and will be produced by SanDisk and Siemens in both flash and ROM versions. SanDisk, (...) will manufacture the flash MMC while Siemens, (...) will produce the ROM-based MMC. (emphasis mine)Even after extensive research, I still failed to find more than two products where ROM-based MMC were used:
- Some PalmOS devices used ROM MMCs for software distribution
- Nokia N-Gage (which is notable for being a huge commercial failure) likely used them for retail games.
Siemens themselves have noped out of being a ROM-only vendor somewhen between April 24th, 1999 and October 22nd, 1999. At first glance it might look like they ragequit MMCA altogether, but that's not the case - a chunk of the company got spun off into Infineon Technologies AG, which went to vendor both flash and ROM cards, as well as host controllers; By 1999, it must have been obvious that Flash is where the money is at.
Interestingly, Siemens was briefly absent from the vendor list after the split, returning somewhen around April 2000 as a manufacturer of cell phones, quickly following in May with PDAs. It might have been an oversight on the webmaster's part, but otherwise it shows lack of diversification. Leading a standard without proper dogfooding is often a recipe for disaster.
Having read (and implemented) the standard beforehand, reading the press release is somewhat of a rollercoaster. It feels like every involved party had a different idea of what a MultiMediaCard should do, beyond storing data:
Nelson Chan, SanDisk vice president of marketing, explained, "One of the major benefits of the MMC is having a DOS/Windows file structure which makes it very user-friendly for desktop connectivity. The MMC will be a highly-supported product, and a number of customer development tools will be provided for the card. These tools will facilitate an easy design-in of MMC and will support downloading of new applications from third party software developers."Half of those are buzzwords, the other.. well, thankfully, "downloading of new applications" never came into fruition (or at least I didn't find any later mentions). From other things that are absolutely bonkers: MMCA's main page used to proudly proclaim:
(...) up to 30 cards can be connected to a single bus.Horrifying thought, right? Worse, this is entirely real (and it even got carried onto SD cards). I haven't heard of host devices that for certain use more than one card per bus, but in the handshake, the MMC standard goes out of its way to support it, so they probably exist.
SD comes onto the scene
SD started development in 1999, with the initial version coming out in early 2000. Comparing SDA's member page (August 2000) to MMCA's member page (November 1999), there are many more common members than you'd expect, suggesting that some jumped the bandwagon early. The SDA list notably includes SanDisk, but is missing Siemens and Infineon.
SD's roots are apparent to anyone who tried implementing, or at least glanced over both standards. Unfortunately, while simplified SD docs are available on their page for free, the full MMC spec never was public. Initially they only distributed it to MMCA members, but starting 2005, anyone willing to pay a hefty sum could get it. Either way, I can't really link it here.
The abridged version is as such:
- Most of the protocol is common, down to the exact same command IDs.
- Slight differences in how extended card metadata is presented: MMC has EXT_CSD (Extended Device-Specific Data), SD has SCR (SD Configuration register)
- SD Association changed the response to a few commands needed to enumerate a card (just to make everyone mad)
- ... but not in a way that can't be worked around
- Later on, the standards diverged with extra functionality, but the base protocol stayed backwards-compatible.
It's annoying how they copied the vast majority, and changed just enough to break interoperability. But, surprisingly, SDA has also brought some nice things to the table, and for both parties.
Part A2 of the SD spec defines a generic SD Host Controller (SDHCI). While both MMC and SD supported an SPI mode, for faster applications a purpose-built interface, a Host Controller, was a must.
Of course, there were host controllers before SDHCI - MMCA's product page even lists a bunch of vendors that could sell you one; But as far as I could find, they never had one, coherent standard. My suspicion is reassured by a cursory glance over linux's drivers/mmc/host directory. Most drivers in there are variations on SDHCI or extensions thereof; The remaining few are custom, and don't seem to have much in common (besides the purpose, anyways).
Finding any coherent info on prehistoric host controllers is almost impossible today. At some point MMC Host Controller became an alias for SD/MMC Host Controller, which is just a quirky way of spelling SDHCI. Browsing historical Linux sources doesn't help either, because Linux didn't have MMC drivers way until SDHCI was commonplace. The only relevant documents I found about this dealt with the SPI mode - which isn't to say that the dedicated access mode wasn't used before SDHCI, it just shows how closed and member-only the standard really was at that point.
The security extensions
SD's introduction is essentially remembered as "MMC, but with DRM". But, what if I told you that not only did MMC have DRM, it did before SD cards even managed to catch on?
Keitaide Music: the first DRM on flash cards
Picture 1 - of course it had a kawaii mascot
First SD-capable devices were introduced in March 2000; By that time, MMCA Technical Committee was already hard at work with Fujitsu, Hitachi and Sanyo to define the Keitaide Music DRM standard (jp. "Music on Your Mobile"). The final version was released in June of the same year. Subsequently, Japanese carrier DDI deployed it in November, with a service called "Sound Market", available on select cellphones:
"Sound Market" is a service that allows users to download compressed audio data of music, entertainment, education, and other audio information. The downloaded content is stored on a memory card and can be played back on a player. The data consists of encrypted content and a license key for decryption. The content will include music, entertainment, education, culture, language, and nature. A 45-second sample of the content is available for listening. (...) Content fees have not yet been determined. The content fee will be charged together with the communication fee for downloading (13 yen per minute).(...)
DDI plans to aggressively promote a large-capacity content download service that takes advantage of its low rates and the wide area of 64 kbps data transmission, the fastest in mobile communications. from ascii.jp
translated using deepl w/ manual corrections
The whole standard is formed as an extension on top of MMC 2.11. It introduces a new Extended CSD register (which would later get absorbed into the main standard - and in an incompatible way!), based on which the host detects if a card contains additional security features.
Picture 2 - diagram of an extended card
Supporting cards were expected to have a TRM ("Tamper-Resistant Module") for storing key material. Inside, an MPU (... media processing unit? nobody knows. probably an 8051) would deal with license management, as well as encryption/decryption of data.

Pictures 3,4 - a horrible flow graph, showing a "secure" write procedure
According to published example flow diagrams (seen above), the encryption was supposed to happen on the card itself, not over the air. This already throws the standard into the Security-by-Obscurity territory. As effective as it might have been in practice, in principle the encryption (3DES, btw) was next to useless - If one could just ask the card to decrypt the data and send it out with no auth whatsoever, "licenses" and "play counters" that auto-decrement don't matter.
It's unclear how much success Keitaide Music ever saw. The media coverage was quite poor, but from what I could gather, the consortium renamed itself to UDAC. As per UDAC's new website, the rename was to expand the technology beyond the use in mobile phones. UDAC went silent mid-2004, with their site finally going offline five years later.
SecureMMC, and other oddities
The only reliable information I found about SecureMMC comes from various press releases; The initial one announced the new standard in late June 2001. It gives some horrifying insight into what they came up with:
(...) The SecureMMC is similar to a Smart Card implementation, on which it is based. (...)No. This can't be right. No no no no, no way. They didn't...
So.. I dug deeper. And... I found a patent. US8539183, first filed in 2003. And sure enough, they made a SIM card kiss with an MMC card, sloppy style.
A memory card of one published standard, such as the Multi Media Card (MMC) or Secure Digital Card (SD), is modified to include the function of a Subscriber Identity Module (SIM) according to another published standard. The controller of the memory card communicates between electrical contacts on the outside of the card and both the memory and the SIM.
Picture 5 - horrors beyond my comprehension, src: patent US8539183
Initially, the patent being filed after the approval seemed odd. But then I found another press release from 2004, where MMCA finalizes the second version of the spec - maybe that's related?
Curiously, SecureMMC v2.0 was still "coming soon" 3 years later, when MMCA dissolved into JEDEC, the independent standardization body. Hence, it isn't fully clear whether this patent is SecureMMC or if I found another cursed, very similar thing.
Unfortunately, it's unclear whether anything actually used SecureMMC. Beyond press releases and mentions on a few web pages, it's almost impossible to find info about it, let alone devices designed with the secure part in mind.
e-MMC Security Extension
In 2007, MMC Association dissolved, and the standards were inherited by JEDEC. Just before that happened, they went to formalize their last standard extension - the e-MMC, also known as the only MMC implementation that actually stayed relevant. e-MMC was by definition a single-chip solution (not counting the controller, often already integrated with the SoC); This allowed it to fill and dominate a niche within cheap devices that otherwise needed multiple flash chips alongside a separate controller. It's still used to this day, mostly in phones and cheaper laptops.
Years later, JEDEC defined JESD227: throwing away all the cursed SmartCard shenanigans, it's a scheme implementing host authentication alongside standard AES-CBC/AES-XTS encryption in hardware. Boring as hell, but also the first time MMC got any actual "security" features that might realistically get some use.
It's not hard to notice that MMCA was.. DESPERATELY trying to hold onto whatever they could to keep their technology even slightly relevant - and I haven't even mentioned miCARD (what if a card had MMC and USB at the same time?), ATA on MMC (??? WHY), and marketing stunts like MMCplus (AFAIK literally the same tech as MMC, just increased clock speed)1.
#1
For some of these, the only source is a random presentation from 2007's Flash Memory summit, linked in the sources. Others are documented more widely. Also, i'm still not sure whether MiCard ever got released, it feels like vaporware.
Even the standard itself made some crazy assumptions that never made sense in practice.
Those are all signs of a problem - and I suspect that it went on behind closed doors for close to a decade.
SD was destined to win
Despite what many think, SD didn't really have a competetive edge with DRM. And even if it did, it's not like it mattered in the grand scheme of things - the userbase of the "secure" features was miniscule. What SD Association had was a solid vision to focus on being a storage standard first and foremost, and everything else (SDIO) second. Introducing SDHCI also removed a barrier of entry that MMCA seemed not to care about.
Nobody knows what happened behind closed doors. But one can speculate.
MMC is, and always was, a standard defined by a committee. Every standard designed as such ends up being somewhat detached from reality, but I think that MMC Association also managed to detach itself from some of its core members.
Considering how long it took Infineon to join SDA (they only joined in November 2002, with even core Siemens becoming a member sooner), it reeks of inability to find common ground on issues that actually mattered.
All in all, MMC is an awfully interesting piece of tech history to look at, and I'm glad I could show you a part of this rabbithole.
Notes:
- MiCard, ATA on MMC, MMCplus - For some of these, the only source is a random presentation from 2007's Flash Memory summit, linked in the sources. Others are documented more widely. Also, i'm still not sure whether MiCard ever got released, it feels like vaporware.
Sources:
... every link sprinkled throughout the article, but especially:- 2007 Flash Memory Summit presentation
- that hilarious patent
- Press releases mentioning SecureMMC: 1, 2, 3
- SD slander
- Keitaide Music whitepaper
- Keitaide Music Technical Spec 0.90
(if you see any obvious inacurracies, please contact me with a correction. finding good info on this topic is one hell of a ride.)
big thanks to mei, April, yavien, Lili, Linus, and kleines Filmröllchen for proofreading this post!

Comments:
> It feels like every involved party had a different idea of what a MultiMediaCard should do, beyond storing data this needs an alignment chart
Jesse at 26.09.2024, 18:11:36Great article. A few weeks ago I got curious if modern SD cards still have DRM features, and can I, with an Arduino, see or use them, or in fact if *anyone* ever used them, and it was hard to find much info. I got as far as "you can pay thousands of dollars to get the spec" and then gave up, because I was merely curious. One thing that I did learn, which I found amusing, but you probably already know, was that the origin of the SD card logo was Toshiba had it sitting around from a failed Super Density disk project (a DVD war combatant), and let SD use it, which is why the D looks like an optical disc despite SD being very definitively solid state.
Bsdimp at 02.10.2024, 03:37:57My CPAP machine has a SD card that stores some of the data using the Security features...
By commenting, you agree for the session cookie to be stored on your device ;p











