Proxy

video: https://www.youtube.com/watch?v=A9QtdeWqC6U

I will talk about what it is like to build a product today, as opposed to sometime in the future. Who are we? We're a hardware and software company. We started in the physical access space where we're building NFC reader hardware, wearables, and phone wallets, or phone apps for enterprise physical access control. Think employee badges for getting through doors as well as logging in within your workplace and meeting rooms and things like that. We push the mobile version of this into the physical security industry when we started; it was an afterthought when we started, and we made this a first-class citizen. We worked with a few phone manufacturers to make this a reality. We're also involved in standardizing some of these protocols to make them more universable, the CSA ACWG alliance is leading the way there.

So what are we building right now that is relevant here? To some extent, the access control stuff is our legacy as a company. One of the things that we found is that there's a bigger need for managing credentials and digital identity that isn't just for access credentials but any sort of credentials, and it fits very nicely into the world that the cryptocurrency community has created.

What we're building today is a wearable hardware wallet and a complementary mobile based software wallet that is an evolution of our previous Proxy App that will cover more of the digital identity usecases as well as crypto-asset storage. We see these as complementary; ideally this is creating a single product where software and hardware work together to give you a better experience which has been our motto as a company, getting those to work nicely together.

I mentioned wearable hardware which has some unique challenges. There's extremely limited power, limited physical space, and we're talking about the form factor of a ring so it's probably smaller than you can imagine. Limited IO capabilities, which to some extent is to our advantage here because we sidestep some of the secure UI problems that Mark has mentioned in his presentation. We kind of don't have a lot of IO. You have secure radio access through NFC directly bound to the secure element (SE) which is the IO we have, but it's also fairly secure IO.

Since we're so limited in space and power, we work with a high degree of integration and we're not dealing with discrete components often. We are talking about multi-chip packages which are highly integrated, to save on space and power and routing area on the circuit boards, which of course results in very few options for us to choose from because we're limited to what integrated solutions are already available and we can't pick and choose best in class for each individual component.

As a wearable device, there are table stakes: we're not building a single-purpose device, because as a wearable it has to do all the things that people expect it to do. It would be pretty difficult to convince people to wear 10 rings or glasses or wristbrands where one of them is your mobile driver license and one of them has your bitcoin, and another one you use to get into the door and you forget which finger is which. This is the same category of devices as something like a phone or watch that has to be fairly multi-purpose and it has to work with things that people already use today.

This gets me to a real world live usage conversation. There was a nice article Wallets Abound - The Daily Gwei #488 which talked about the proliferation of cryptowallets and which direction that is going. They focus on user experience which reflects the convenience and quality of that experience, crossed with the level of integration with existing systems and a good enough-by-default level of security that will actually make a wallet whether software or hardware that actually reaches mass adoption and brings some of these use cases to the masses so to say.

When I read that article, this is exactly the sort of thing that we at Proxy are focused on. That's spot on to how we think about things and what we're building.

I listed a few things that people are already doing today with various hardware devices: cards, hardware tokens, phones, badges, tickets, digital IDs, crypto-assets, DIDs, etc. There is existing legacy infrastructure and also new infrastructure, coming from physical access control awareness of needing to interoperate with that infra, because we talk about devices that hang off office doors for decades. We have built and deployed some of those devices; but those things aren't going to get replaced, and if you want to switch how people do things by having everyone install new terminals then you're probably fooling yourselves.

Some of the challenges that I've seen firsthand trying to design a product that does some subset of those functions.

There is limited functionality in SEs in general. Some of them are black boxes, and some are more open but they are largely just Java SmartCard JavaCard runtime environments. A lot of the market uses this, there are existing JavaCard applications. That's a somewhat specialized runtime environment with persistent memory and other things like that.

The next challenge I want to talk about is something I see caused by the certification requirements. For existing applications like payments, access control, there's costly lengthy certification processes. GlobalPlatform, Mastercard, Visa, transport networks. This costs a lot of and they end up freezing your entire stack so you can't change a single thing, and this leads to predictable market dynamics. The vendor is not going to change something that will trigger re-certification unless they have a large commitment from a big player like a phone manufacturer that actually wants that functionality. It's not necessarily a problem of the specs and standards not being there, it's unwillingness to implement the features quickly because of those market dynamics. JavaCard 3.1 has been around for a few years, and I have not seen a single SE that implements it yet. Even 3.0.5 JCAPI which is 7 years old now is not that commonly adopted. (JCAPI 3.1 from 2019, 3.05 from 2015). A lot of mass market chips are stuck on 3.0.4 API versions. NXP SE050E has added AES-GCM support, just at the start of this year, and that's brand new silicon before a small player like Proxy can use in a product design before it becomes to volume production-- we don't buy millions of chips at a time, we buy thousands. So it's quite far behind. You will hear someone say AES-GCM is already deprecated, yet it has only made it into this piece of silicon as of this year.

The last sort of challenge I wanted to talk about is the lack of single-point of view from anyone on these manufacturers or vendors that often make these chips today. Quite often the entire spectrum of expertise doesn't exist in-house. The chip vendors are specialized at making silicon or integrating pieces of silicon into a chip package. Sometimes they are RF experts, memory experts, silicon manufacturing experts, but they might not have the software expertise and the security is often outsourced. Or vice versa: you have software houses trying to buy the chips off the shelf and they don't have influence about what goes into the hardware and they use the chip as a black box. One of the big problems with this that I see is that the people who are making the major components for some of these products are not the people who are making the products. There's a disconnect between what the product requirements and what the components can do because there is not a tight feedback loop. I come from the software world, and looking at a lot of the software packages that have become hugely successful recently, like the various data store implementations and things like React, so many of those have evolved from a product company solving their own problem be it Facebook or Google solving a problem they had and then open-sourcing a piece of infrastructure code and then they can solve that product problem, and other people have the same product problem and they can use it. But the component evolved out of a product need; this doesn't happen in hardware chips, because the people making the hardware are not also making the products. I hope to get out of this closer integration and get more information sharing as well.

What should we do? Just a couple of thoughts on what would help things.

Let's find ways to build architectures where some of the existing applications can co-exist with some of the new stuff being developed by crypto-wallets for example. Again, just going back to our requirements, we don't have the luxury of a single function device like a Ledger that you plugin and use and put it into a safe... we need to support the existing applications as well as the new stuff we want to build, we can't just ignore that existing stuff runs on JavaCard.

If integrated solutions are being developed, they should be developed with modularity and flexibility so that as a consumer of that package we can choose how to enable certain things or when to do that or other settings. I know that to the chip maker this means more complexity and switching logic, but it will make it more worthwhile to produce long-term. If the integrated package can be used for more use cases than the narrow one the manufacture foresaw, it can have more longevity as a chip.

I have mentioned this with certifications, but some of these things need to move slowly for good reasons. At the same time, you don't want that to be the limiting factor. You want parts of the system which can evolve faster and have the ability to do so.

That covers what I wanted to talk about and what I'm hoping to discuss in the Q&A sessions later as well. I'm available for other questions or other conversations happy to have more of these sessions.

Bryan just posted into the Zoom chat the collaborative notes link. To be clear, that particular document is not completely private so if you put your name or contact information in there, it may be available to more people than just this community so just be aware of that before you add your name to the attendee list at the top of the shared document.