Towards a More Open Secure Element Chip
bunniestudios.com
bunniestudios.com
A secure element chip does not need a completely libre/open design to support software freedom, but it does need to allow end-owners to run whatever software they would like - not subject to a third party's approval. To that end:
1. The chip needs to be able to be completely erased, having all keys zeroed out, at which time new keys can be loaded and/or internally generated. Signature verification keys are zeroed out to establish a new root of trust, and program/memory keys are zeroed out to maintain the security of information previously entrusted to the chip.
2. Resetting the chip should take a configurable amount of time (days to a month), either based on internally counting the clock or external proof of work, to protect against evil maid attacks by those with temporary possession of the hardware.
3. If there is any remote attestation functionality, then the reset procedure must output the attestation signing keys, including the private parts. This way the manufacturer (or any downstream integrators) cannot record the public identity of the shipped attestation keys to create a trust relationship that would prevent the ultimate owner from running software of their choosing.
For software freedom, these aspects are much more important than the design and licensing of the computation core(s). Let them ship ARM. Let them ship only ARM. Let them ship a proprietary ISA that needs to be painstakingly reverse engineered over a decade. Spend your social capital making sure the ultimate end-owners of the chip remain in control of their own devices! This is what is critical for open source.
Keys don't have to be open source.
Re (2), the way you defeat evil maid attacks on boot or wake is by using a TPM and measuring every bit of firmware and software loaded (to some point) so that local storage decryption is not possible unless you're running golden code. The hard part is stopping evil maid attacks on running systems.
Re (3), for open systems you really need any remote attestation to be at the option of the end user or the operating system that they choose to run (but the end user must have the option to run an operating system of their choice, which then might not implement remote attestation).
TPMs got these things right, but they're not SEs. TPMs could be SEs, but they're missing necessary functionality. I'm imagining a BPF-style system where you'd get to send bytecode to be interpreted with access to various loaded key objects (handles), and which would be able to execute TPM commands (subject to policy) and use their outputs without exposing them to the user, with the program's execution and availability of its final outputs being conditional on satisfying some relevant policy. Because so many systems have a TPM, a TCG TPM standard update that allows for a very limited and TPM-centric SE to be implemented with a TPM firmware update would be very interesting.
> For software freedom, these aspects are much more important than the design and licensing of the computation core(s). Let them ship ARM. Let them ship only ARM. Let them ship a proprietary ISA that needs to be painstakingly reverse engineered over a decade. Spend your social capital making sure the ultimate end-owners of the chip remain in control of their devices! This is what is critical for open source.
Yes, the amount of software built to run in SEs is minute, therefore it's not that big a deal to expect vendors to recompile that software if a new version of the SE were to use a different ISA. I'm a bit surprised at the focus on RISC-V, but I'm not annoyed by it -- if it really costs them little, then I don't see the problem, and having the option is certainly interesting.
Mind you one could still still hide logic outside the scan chain but it should still be discoverable thru scan.
How did TPMs get these things right? To me, it seems they've gotten them direly wrong by letting the manufacturers create privileged keys.
I wrote my comment from the perspective of making something better than modern TPM implementations, iff they get the ownership/control issues right.
I don't understand your counterpoint to my (3). It's not enough for the OS to have an option to not perform remote attestation - the owner needs to have the ability to perform a mock remote attestation. Otherwise a remote party can just demand remote attestation be done, and the owners's "choice" will have been nullified.
Even if TPMs came with no endorsement key certificates, the platform could still trust-on-first-use the TPMs and create "privileged keys". The only way to prevent that would be to make TPMs useless.
> I don't understand your counterpoint to my (3). It's not enough for the OS to have an option to not perform remote attestation - the owner needs to have the ability to perform a mock remote attestation. Otherwise a remote party can just demand remote attestation be done, and the owners's "choice" will have been nullified.
I don't see how to do that without the party demanding attestation somehow establishing trust in your device, but that requires "privileged keys", and surely that party gets to say "no" (at least technologically; legally is another matter).
There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices. Hard to get that but also make it impossible for consumer personal devices to attest. Also, users do get better security from attestation, at the cost of being at the vendors' mercy regarding walled garden lock-in. TPMs are neutral in this, enabling both, secure systems and DRM, and preventing neither.
I assume by "platform" you mean a remote party exerting control, bordering on non-consensual, over your local computer? If the hardware is not shipped with keys, the way to get around that would be to generate your own key external to the TPM, and load it into the TPM. Then the "platform" could trust that first-contact key all day long, but you would retain control.
> I don't see how to do [mock attestation] without the party demanding attestation somehow establishing trust in your device
That's the point of my requirement for the SE/TPM to spit out the attestation signing key when in reset mode. It grants the owner the ability to create mock attestations of the device as the previous owner knew it. Going forward, the owner can walk away and have the device create attestations that they can trust, with the condition that they aren't out of contact with the device for longer than the reset period. (The reset period requirement is what creates the distinction between a mere possessor, and the bona fide owner)
> There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices
Yes, these are exactly the useful scenarios I envisioned when I wrote my comment, and would be fully supported with the requirements I laid out. What is not supported is claiming to sell someone a piece of hardware, while retaining indefinite control over it.
I mean the OEM who issues any "platform certificates" (in the TCG sense) for keys in the TPM's "platform key hierarchy". That would be, e.g., Dell.
> If the hardware is not shipped with keys, the way to get around that would be to generate your own key external to the TPM, and load it into the TPM.
If you have to do that every time, then you're always storing that key in the clear, and then you get no security advantage from having a TPM.
If you have to do that once and then you get the key back wrapped in a secret key only the TPM knows, well, TPMs pretty much support that. And now the platform can do the thing you don't like: ship with such a wrapped key (and certificate for it), which then enables operating systems to implement DRM.
You really can't get away from this. It's just not possible. Either you have a TPM-like device that is useful, or you don't have one, or you have one that's not useful (which is the same as not having one).
> That's the point of my requirement for the SE/TPM to spit out the attestation signing key when in reset mode. It grants the owner the ability to create mock attestations of the device as the previous owner knew it. [...]
Unfortunately that would ruin the TPM's security features in general. It would make it useless for enterprise, for example.
> > There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices
> Yes, these are exactly the useful scenarios I envisioned when I wrote my comment, and would be fully supported with the requirements I laid out.
Doesn't work. See above.
> What is not supported is claiming to sell someone a piece of hardware, while retaining indefinite control over it.
You can change the seeds any time you like.
It will never be used, unless the RISC-V core turns out defective, which is extremely unlikely.
This also means that you can get two (or more) blank TKey devices and provision them with the same UDS, creating a backup key that you can put in a safe place. I'd recommend to at least have different Unique Device Identities, to allow you to see which of the devices you use when connecting it to the host.
The bitstream, with the UDS is stored and locked in the FPGA non volatile configuration memory. It will not protect against a prepared evil maid-attack that gives the attacker enough time to dismantle the casing and perform a warm-boot attack. We are working on ways to make that attack harder, less feasible.
This is straight up false in the standard model where protocols are what mediates between otherwise-independent parties.
If a remote party can verify the software I am running on my machine against my wishes, that creates a security vulnerability that prevents me from running software of my choice.
> This is straight up false in the standard model where protocols are what mediates between otherwise-independent parties.
I've answered this elsewhere. TPMs are neutral technology enabling technology that you might approve of and technology you might disapprove of.
> If a remote party can verify the software I am running on my machine against my wishes, that creates a security vulnerability that prevents me from running software of my choice.
TPMs do not prevent you from having opt-out.
The matter of whether someone can give you only a binary choice of opting into or out of walled gardens is a market/political problem. I don't see how to prevent walled gardens using technology, especially when walled gardens vendors can make it so you can only access the walled gardens on devices that they manufacture (or bless) -- it's their tech, so what can you do to make it not possible for them to implement lock-in? It's just not possible.
And I strongly disagree! A TPM with an attestation key that is known to the previous owner (eg manufacturer or distributor) allows the previous owner (and everyone who trusts them) to compel the current owner to verify what software they are running on their own machine. The presence of the neutral hardware capability, plus the non-neutral treat-owner-as-an-attacker security property that the owner cannot read the private attestation key, creates a non-neutral security vulnerability for the owner. Hence my point (3) to mitigate this vulnerability by making it so that the owner can always choose to emulate an attestation. This property would make the hardware feature actually neutral.
> it's their tech, so what can you do to make it not possible for them to implement lock-in?
The problem is not set top boxes and other narrow-purpose devices created by vertically integrated companies - code signing is enough to lock those down and guarantee the creation of e-waste. Rather the issue is general purpose computers including hardware that allow remote parties to dictate what code you're running when you interact with them. For example, a bank that says "for [our] security, you must run a known copy of MS Windows with a known copy of InterChrome Explorer to access our website" (or analogous proprietary environment). The market basically moves in lock step, so you won't be able to choose a different bank (just as with the now-common "SMS 2FA" hassle). So given the basic non-neutral capability, corporations can gradually shove the general purpose computing genie back in the bottle, rather than having to make due with trusting device owners.
With binary/proprietary software, a similar dynamic exists right now. But for important cases it's possible to reverse engineer protocols and make third party clients. Owner-hostile remote attestation closes off the escape. This further pushes us into computational disenfranchisement, where the computer you purportedly own, that's sitting right in front of you, is enforcing the rules of the corporate-government power structure rather than functioning as your agent.
We do need to win the battle in the market, but to do that we at least need an option for people to buy that respects their freedom. Saying "buy this corporate phone and then run this procedure to change the TPM key [destroying your ability to use corporate-based attestation]" isn't a compelling story, but saying "buy this freedom-respecting computer based on a freedom-respecting TPM" is. We need enough of the people doing the latter that it is market-infeasible for banks et al to require remote attestation.
The user can change the seeds and this stops being the case. Also, this feature is very useful in enterprise settings. Useful here, harmful there -- that's what makes the technology neutral. Even if TPMs didn't have endorsement key certificates, the platform vendor could add its own -- TPMs would be pretty useless without being able to derive keys from seeds or wrap keys, but having that feature is enough to make possible what you dislike.
> Saying "buy this corporate phone and then run this procedure to change the TPM key [destroying your ability to use corporate-based attestation]" isn't a compelling story [...]
You wouldn't say that. You'd say "buy this [device] and install [certain OS] on it". Why would vendors pre-ship the thing that they don't want? The user has to do something, but it can be made easy.
Not in a meaningful way. If you do that, the MAFIAA et al. will just block all of their stuff from that device from then on.
The harm is we're still perpetuating DRM crap. The music industry has accepted that Spotify's DRM can be trivially broken and completely given up trying to police BitTorrent... it's time for the movie industry to realize the same. Sadly, Netflix failed to get enough dominance to bend over and cane the movie industry into submission, and regulatory agencies worldwide just accepted happily that movie studios went all-in on vertical integration again.
Having a device be able to store and use secure keying material that cannot be read back out seems like a very useful basic property. A basic property which directly implies being able to store keys for decrypting media content, thus making for a better DRM scheme than could be achieved with a fully-debugger-able processor.
Of course, I could missing a way that this property could tweaked to neutralize some of its downsides - akin to how my original comment laid out slight modifications to the usual TPM/SE requirements that would prevent much abuse of TPMs/SEs by centralizing entities.
> The performance of older processes is also not sufficient for the latest cryptographic systems, such as Post Quantum algorithms or Multiparty Threshold ECDSA with Identifiable Aborts. On the upside, one could understand the design down to the transistor level using this process.
It would be great to see support for PQ and MPC algorithms, but what would make that easier would be SE programmability with access to the base primitives. The specific title reference implies GG-20 (which the original paper is broken, revealed in later papers such as the Alpha-Rays attack), so that would suggest a need for an SE that could expose field element arithmetic (both for DKG and signature creation) and support for Paillier, but even just having the former would be a major boon, as you could implement MPC protocols that rely only on base DLog assumptions like DKLs18 and 19 which use oblivious transfer (albeit with some matrix operations). Any news on this that can be shared at this time?
The specific citation was provided because MPC algorithms span a pretty big range of computational difficulty, depending on the features you require and the primitives you assume. Narrowing it down to an exemplar algorithm (even if broken) helps pin the analysis to a given complexity range.
It's also interesting to note that some MPC algorithms assume some amount of secure and real-time communication with an oracle to assist with key distribution, which means you're possibly having to stuff a TLS stack into the SE.
https://tillitis.se/ https://github.com/tillitis
The TKey is basically a tiny, RISC-V based System on Chip in a tiny FPGA. The SoC has a minimal interface to the host, a simple context based memory map and a FW to allow loading applications and generate application base secrets.
The SEs you can get without NDAs are invariably fixed-function models which you can't program yourself, which aren't interesting at all to me. There shouldn't be such a thing as an "OpenPGP smartcard" (yet there is), there should just be generic programmable smartcards I can program with an application of my choice.
The sad thing is such smartcards do exist, you're just not allowed to have them because they're all locked behind NDAs (e.g. the ST32 line - not to be confused with the popular STM32 microcontrollers by the same company). These typically feature a 32-bit ARM core and flash, and are used for bank cards and so on. And you can't have one.
Literally all I want from a secure element is:
- Some nonvolatile storage which can only be accessed by the code on the device
- A way to flash a new program to a device in a way which causes all data on the device to be securely erased
- Smartcard-like physical hardening
If bunnie makes this happen I'll be very happy. But his mention of "if we release an updatable chip" sounds... concerning? It sounds like he is focusing on people being able to audit the code they're shipping rather than ship their own applications. Perhaps he could clarify what "non-updatable" means for the normal SKU?
One additional issue is the availability of non-volatile storage. To my knowledge "high-performance" processes can't actually use flash, and flash requires a specialised process. This leads to SoCs (as opposed to MCUs) tending to use OTP eFuses to program security keys, which is very troublesome as it makes it largely impractical to use them in an owner-controlled way. You essentially have to permanently "damage" the chip to enable secure boot. The ability to wipedown the device fully, as described above, is essential to a device which is practical to use.
I'm not sure how MCUs with on-board flash get around this; perhaps they are just built outright on a flash process. They could be multi-die but that would presumably add cost. The mention of using ReRAM is interesting, I wonder what's motivating that.
(The STM32 line of MCUs, while not hardened for security purposes, does at least have readout protection. But frustratingly, it can't be disabled once enabled, which prevents the "wipedown" scenario mentioned above. I also suspect that Oxide's work on using off-the-shelf MCUs for boot security processes, which has resulted in them discovering all of the dubious and frustrating things about these MCUs from a security perspective, means they'll be quite interested in the development described in this article.)
This is driven by the paying customer (not the end user: but the entity actually writing checks with lots of zeroes on it and taking in truckloads of chips).
It is a fact that the biggest, highest volume paying customers to date for SEs would assume that such chips could only be updated through means that the customer controls. Thus, a business manager doing volume-driven research to craft a chip specification for such a market would reasonably conclude this is a mandatory checkbox for generating volume orders.
The flip side is the assumption that nobody in their right mind would pay for a chip that could be fully wiped and/or updated by end users. And to a first order, the conclusion is correct: I can't think of anyone who would write a check big enough to fill distribution channels with such a SKU. Keep in mind that chips are run by the wafer, and things don't get interesting until you run about 25 wafers in a single lot, so you're looking for someone to underwrite the cost for upwards of 100k devices until a sustainable market for such fully updateable chips materializes.
This is where the "obviousness" of an open source approach comes crashing into the reality of market-driven hardware economics. It seems pretty obvious to people like you and me that we should have fully updateable SKUs that can be wiped and provisioned by end users. But there's a chicken-and-egg problem of building the hardware, so that OSS developers can write the software stack, then hopefully getting adoption by volume businesses; but volume business wouldn't adopt until the hardware was cheap enough and the software stable enough.
The angle I'm hoping to exploit is that because the chips are done with no OTP and only ReRAM, we can release a fully-open and updateable SKU as a late-binding wafer sort option. So instead of having to buy a whole lot of wafers, we can split out a portion of a larger run as the "open source developer's" SKU, at a volume that could be underwritten with say, a crowdfunding campaign.
Thus, you'd have the same design, fabricated using the same masks and literally on the same wafer, but based on how some ReRAM bits are configured in the factory, one will accept updates, and the other will not. It's a compromise, but that's the angle I'm trying to work, at the very least. And until someone is willing to step in with a few million bucks to make the demands of other paying customers irrelevant, it's maybe the only practical approach I can see at the moment to break the chicken and egg cycle.
I think the team is on-board with the approach, but there's a lot of technical details to work out, which is why there is an "if" qualification. For example, if you totally wipe all the ReRAM, but you need some extant code to write ReRAM in the first place, you again have a chicken and egg problem. This problem is solvable at wafer sort using probe pads that can put the initial code in place to allow bootstrapping, but how to extend this to a convenient user-accessible solution is an open problem. This is particularly troublesome for SKUs that are destined to be packaged in minimal packages, e.g. an 8-pin SO package or a smart card format, where you simply lack the pins to expose a provisioning port. This is also, unfortunately, where all the volume is.
It could be that the open source SKU simply comes in a package with more pins and we burn precious I/O to expose something like a permanent JTAG interface. Muxing over the JTAG pins to other I/O can also help mitigate the challenge, but it adds complexity and verification/shipment risk if the mux circuit is defective, and again, a hardware bug costs millions of dollars in this scenario so no decision can be considered "trivial". Nobody wins if I try to force some clever provisioning solution that turns out to be broken (also keep in mind that smart card I/O is weird and fussy, it's not a generic CMOS I/O cell).
Also keep in mind that creating a version with a larger package could be a non-starter if we don't also have demand from a "paying" customer to fund the R&D and supply chain to push out that package format. Chip packages aren't free, and also come with substantial up-front costs and high minimum volume requirements.
Everything above makes sense and I really appreciate how you're trying to make this happen for the open source community by intelligently designing a product for both markets.
I infer from the above that you're intending to avoid having any kind of mask boot ROM that could allow programming via the normal interface used to talk to the SE... trying to avoid a boot ROM is interesting, but this is certainly one of the downsides. I guess you could try and hardcode the logic for a serial download protocol over the standard interface to the SE, if you can validate it well...
Wishing you luck and hope everything goes to plan.
Eh, TPMs are fully erasable -- well, the seeds that matter anyways, but not the public keys that sign firmware updates. There's a big difference between "fully wiped" in the TPM sense and "updated by end users" if the latter means "with their own code", but the latter is still OK if in the process all key material is lost that could be used to impersonate the original device.
I.e., an SE that users can flash with their own software should be OK provided that there is no way to impersonate the original SE after doing so. I've no idea if that can be the case for SEs, but it definitely could be for TPM-like devices.
Your previous paragraph succinctly addresses the motivation: high performance processes can't use flash. However, ReRAM is already qualified for use in these processes. Since ReRAM is non-volatile (with a storage lifetime measured in 100+ years) and dense, you can get the benefits of flash and of OTP, and also in a high performance process. By implementing "OTP" as a bank of ReRAM (with a write-protect bit, but still an erase-all mode), the option to do a full device wipe-down is theoretically available with an OTP-like behavior.
- Secret generated inside the device in nonvolatile memory (e.g. during manufacturing)
- During boot, a boot ROM reads the initial boot block, computes KDF(secret, boot block), then sets a lock bit to prevent read/write of the secret in nonvolatile memory
- Boot the boot block, with the secret passed to it (or loaded into a cryptographic glovebox for application use, etc.)
This scheme is remarkably simple, yet can be used to bootstrap basically anything else, since you can write your own bootblock to derive further keys as you wish. Essentially every bootblock gets its own unique secret. You can't change the bootblock, but if manufacturers can commit to an immutable mask ROM, people can commit to an immutable bootblock with enough effort. A managed bootblock upgrade protocol in which a bootblock can choose to endorse a successor based on some arbitrary policy it implements could probably be designed with enough effort.
Not sure if this is compatible with what you're going for though. I could see some people not wanting this kind of thing or not liking a secret they can't access. I guess you could make it erasable and let people set their own secret.
Just some random ideas floating around in my head.
Sounds like you have the right idea in terms of the requirements I discuss above and which people are mentioning elsewhere in this thread. I look forward to reading the datasheets when this is announced.
That's in fact very possible! I've been doing just that, i.e. running an open source implementation [1] of the OpenPGP smartcard standard [2] on a physical card to which I have the root keys.
The card specifications themselves are presumably behind NDAs, though, so I do have to trust the vendor to not have built in anything nefarious, e.g. a predictable/keyed RNG.
> And you can't have one.
I have three :)
The specifications are indeed behind NDAs, but you don't really need those – you can just work with the (publicly accessible) Global Platform application management commands and the Java Card API. The excellent GlobalPlatformPro [3] can take care of much of the former.
[1] https://github.com/anssi-fr/smartpgp
[2] https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3...
May as well add some random smartcard history... I believe historically one of the reasons for this is that most smartcard chips for the longest times were basically an 8051, a made-to-order mask ROM, and a very small amount of flash (too small for much code). So there was a real need to minimise the size of code which needed to be put in nonvolatile storage. I assume JavaCard implementations have their own implementations of standard cryptographic algorithms in mask ROM to avoid the need to put them in the undersized quantity of flash.
But this isn't the case anymore, where you have smartcards with 32-bit ARM cores and which are all flash-based. If there's a way to obtain and program one of these, I'd like to know about it.
The cryptography for these cards is usually provided by the OS or even in custom hardware, mostly for performance reasons: The underpowered 8-bit MCUs that were commonly used for them can't run e.g. RSA in a reasonable timeframe, so they have custom coprocessors for that.
> "I want a smartcard where I can program the actual CPU, not in some VM." [...] smartcards with 32-bit ARM cores and which are all flash-based. If there's a way to obtain and program one of these, I'd like to know about it.
I'm unfortunately not aware of such a thing in the smartcard world, but if you think about it, this just pushes the problem of trust down one layer. At some point, you'll have to trust the hardware RNG to supply actual randomness (and not just the output of a known-seed PRNG).
I suppose it could be useful in some scenarios to get rid of the proprietary OS/VM implementation if you are concerned about bugs there, but in the end, you are still ultimately trusting your hardware vendor.
Or are you mainly interested in being able to use a stack other than Java Card?
You might be interested in this:
It's a USB dongle rather than a smart card, but you might find it useful/interesting nonetheless. The site says they are out of stock but I have a few left. Contact me off line and I'll send you one if you think you'd be interested in noodling around with it.
There are several problems with these:
- The above one uses an STM32, which has an inflexible readout protection mechanism as I mentioned above;
- Readout protection really isn't hardened or intended to provide smartcard-level security, and is usually trivially glitched.
And what is your threat model? The STM32 series are designed to protect IP in industrial applications, so if their readout protection was easy to break that would destroy a substantial portion of their market.
STM32 is vulnerable to glitching, as are MCUs specifically marketed for "secure" applications like the SAM L11: https://chip.fail/
If your MCU doesn't specifically list hardening against glitching specifically, it's almost certainly vulnerable to it (and good luck finding a MCU with anti-glitching measures which isn't NDAware). Best not to take the security claims of hardware vendors too seriously unless you've personally verified things.
Interesting to note these kinds of MCUs are used by things including Bitcoin wallets, etc., rather than purpose-built secure element chips, almost certainly because the latter are all NDAware. The above research managed to trivially glitch these chips. So this is an example of a real harm and security issue being caused by the current state of the SE market and its obsession with secrecy.
> this is an example of a real harm
That depends on your threat model, which is the reason I asked. The SC4-HSM is designed to be secure against loss and casual theft (i.e. a home robbery), but not active theft by a technically savvy adversary.
Actually, you can. German company ZeitControl sells cards you can program on your own in a BASIC dialect [1]. Been years since I last played around with my set, but they're still well in business.
[1] https://www.zeitcontrol.de/de/produkte/basiccard/basiccard-p...
For those interested in contributing I'd recommend the Silicon Salon workshops https://www.siliconsalon.info/ see https://diyhpl.us/wiki/transcripts/silicon-salon/ for the transcripts.
Another distantly related project I'm watching in this area is https://libre-soc.org/ && https://diyhpl.us/wiki/transcripts/silicon-salon/libre-soc/
Why is a stealth mode company interested in an open source strategy?
Isn't that counter intuitive and purpose-defeating?
For example, because the company is not yet fully formed, it doesn't have a website -- nobody has made one, because it's not the most pressing thing to do right now. I don't even think the company has an official logo yet.
They are basically walking and chewing gum by trying to put together their advisory board, while they also put together the details of the corporate entity. In essence most startups go through a "stealth mode" phase because many disclosable details simply do not exist. It's perfectly consistent to say "we want to do open source", but also not have prepared a logo, a website, and an overall corporate narrative.
Magic Leap used to be in stealth mode back in 2016 and there was so much frenzied speculation around it in the media.
Last I heard, they had delivered some headsets of industrial process automation and that's about it.
- secure element is in every credit card
- secure element is in every cell phone
- secure element is in every modern passport
these aren’t simple use cases. these have national security implications. i foresee this going the opposite direction as more critical things rely on secure element more individual proprietary implementations will emerge.
it’s still a standard. you can still develop on top of secure element. but who really benefits from it being open?
Developing for SEs normally require signing boatloads of NDAs. This makes it hard do talk about weaknesses, things that simply could easily be improved (in support libraries for example).
By having open designs, open source more people can review and decide for themselves if they are ready to trust the SE. And hopefully more bugs can be found, issues can be fixed and things can be improved faster. This will benefit the users and the societies as a whole.
(For example, see the Raspberry Pi which helped spur an ecosystem. Also, even the original Pi 1 can still be useful today.)
Those secure elements in credit cards (Java Card platform) and cell phones (SIM) have an open standard. This is natural growth in that standard.