It depends on what you mean by “key”. man… actually this is such a complex question once you start unpacking it…
If you mean “key” in the abstract, like “adding a gym key” and “adding a public transport key” to the chip, then no… this is not the same “key” concept as adding metal keys to a keyring.
The DESFire EV2 chip in the flexDF2 is capable of storing multiple “files”, each of which has a unique AID (application ID) and set of cryptographic keys (keys in the crypto sense). These are called “applications” in much documentation, but they are not software programs that run (traditional meaning of “application”), they are special file types… but just to add confusion to the pile, the point of the chip supporting different types of “files” is that some of the “files” support built-in functions. For example, one file type is just basic binary data storage… it’s a traditional “file”… but another file type is a kind of “purse” that supports special commands to increment or decrement the value stored in that file. This is a convenience and also offers security advantages.
Let’s say you wanted to set up a “stored value” application that used these chips in an offline fashion where you load value to the chip at the front entry gate of an event, and then spend that value at various stations within the event. If the stations are not online or connected, then there needs to be some way to securely load value and remove value from the card. If you just used a standard binary data file, then every single reader would need to have the access key codes to access, read, and modify that data… and every reader would need to be trusted to do so and not mess with the value… and every reader might also be a potential security risk if one were to go missing and reverse engineered. Alternatively you could split out keys for a stored value “purse” application (file) on the chip so that the loading station at the secured front gate area is the only device able to add value to the chip, while vendors around the event have readers that can only only decrement value via a logged transaction, and there is no way for these vendor readers to erroneously add fake money to the chip or even get a balance off the chip (unless that is allowed by key access settings for the file).
Because the chip is 8k you can define multiple files of various sizes… so you could have two 4k “files”, or several 1k files… the trick and problem here is that even though the chip supports multiple file types and multiple files which may or may not even be related, it is still a proprietary file system and absolutely no vendors or applications out there are set up to leverage a shared environment on chips like this. For example, transit companies give you a transit card. They expect to have complete and total control over the chip and make no provisions for deploying their transit app (file) to chips that aren’t theirs… they deploy their applications to the transit cards during manufacturing of the card and there is simply no process to deploy the necessary applications to chips after the fact… especially to chips they aren’t sure they control or can’t be assured are secure (think chinese knock off chips with back door access to data)… so the world will continue to be a right mess when it comes to doing multiple things with a secure chip like the DESFire EV2.
That is not to say that you can’t use an implant for multiple things… it just means that you will very likely be limited to simple applications with low security risk involved (or badly designed security applications) where the simple unique ID (UID) or serial number of the chip is all that is used to interact with a system… think about simple door lock applications that only care about the UID and not any of the stored data… you could add this UID to the “authorized list” of an infinite number of door locks… but those applications are not secure as anyone could read and emulate your UID with easily accessible hardware… so again, true utility will be limited.
This changes a bit when we start talking about something like the VivoKey Flex One and a company like Fidesmo. The Flex One can run java card applets, which really are little software programs that do actually run on chip, but just like the DESFire EV2 with it’s proprietary file system, basically nobody out there is leveraging these chips as a shared environment. However, VivoKey is partnered with Fidesmo, and they are setting themselves up as a kind of “applet store” and attempting to push card ownership out of vendor’s purview and into the customer’s. The advantage to vendors is that they would (eventually) no longer need to worry about manufacturing cards or vending them, they just publish their applet on Fidesmo’s applet store, and the customer brings their own card or watch band or implant to the party, deploys the “transit app” or the “door access app” to their own device, then enroll that device with the transit service or enterprise security system, respectively.
Fidesmo is breaking new ground with this concept so it will not be an overnight change, but we are working with them to get new vendors to publish applets and we even have our own applets we are working on for various things like OTP code (authenticator) code generators, bitcoin wallets, PGP, etc.
