Actual security benefits of Apex over Spark - more security mumbo jumbo :D

Lounge
1

Some may remember, I wasn’t a fan of the Spark series. I did not like the fact that VK keeps the keys, and I much rather like the private key approach the Apex line is / will be using.

My very dumbed down mental image of the authentication between a VivoKey spark and the VK servers is that the implant somehow proves it has a shared secret using symmetric encryption (AES). However the actual process might look, they have a shared secret.

This means that VivoKey holds the keys that your spark implants have.
Now is this bad? Yes. But how bad? Well, now it gets interesting.

Before I get to the point I just want to quickly highlight the difference between Apex and Spark in this context.
The Apex can do some more advanced cryptography, this allows it to also prove it has a secret, but it doesn’t need to disclose this secret to VivoKey. It’s called asymmetric encryption, the point is: VivoKey does not need to keep the keys (if they design it this way, which they most certainly do).

Now let’s talk about “Login with VivoKey”.
When you use this feature on a website, your Spark allows VivoKey to know who you are, then VivoKey tells this service that you are you and you have logged in.

This means VivoKey has the authority over who can login into what account, it’s only protected on VivoKeys side. What I mean by that is that it’s not actually the implant that’s talking to your 3rd party service you log in to (AFAIK).

So, what if VivoKey gets hacked? (as in completely, every service etc.)

On the first glance there really isn’t a big difference here. the attackers will have access to any account, because VivoKey has the authority for these logins. Tehy can just login into anything any VivoKey user has connected their implant to. But that’s the same with “Login with Google” and any other identity provider. This is how it works.

Btw I’m not 100% sure if all of this is true, feels like a good spot to say this.

So what security benefit does the Apex line bring in this context?

As I see it, it’s that Apex users can recover, and Spark users can not.
Once Spark keys are lost (which hopefully never happens) they are gone, every Spark can be spoofed now.
This is not true for Apex as VK should only hold the public keys for asymmetric encryption.

So yeah that’s the only real benefit in this case.

Ofc I’m ignoring the huuuuge security bonus that are all the 2FA related applets :wink:
But that’s another story.

Also since the platform is being redesigned idk show much of these thoughts will stay relevant.

You now know Apex doesn’t really increase security that much for VivoKey services (this is excluding things like U2F etc., I mean VK servers). So, will I get a spark? Eh, maybe, but I def was too harsh on it because I didn’t really think it far enough which I now did, I think.

3 Likes
2

I would say that is all accurate.

This is, in part, why the new platform is being modularized such that the symmetric keys are held in a separate “chip db” server with minimal service and extremely simple API interface for confirming challenges and responses, without ever handing over the keys to even internal services. The 'chip db" server is also only accessible to internal servers via the private VivoKey network (non-routable non-public IPs), and treats that network as hostile. There isn’t even SSH enabled on the public or private network for the chip db server, and both interfaces are firewalled. The public interface is completely firewalled and route-blocked. Finally, VivoKey developers and team members are not allowed access to the chip db server or they key database on it. At this time only I am personally able to access this database to post updates when I program new chips into the database. There will be a business continuance plan in place that will release access details for this server if anything should happen to me.

Assuming VivoKey servers are hacked, access to operational code would allow attackers to change the code on the service side to basically ignore the chip database server completely and just approve any scans they want… tantamount to having the keys, but very much not the same thing. Still, we are designing Apex support within the new platform to leverage the assymetric features of Apex so we do not have to store or manage (or protect) the private keys within your Apex.

Probably the most interesting benefit to using Apex over Spark is something not yet touched on - key cycling. The Spark keys must be written and locked by design. The chip only remains secure if the keys are locked away, so this is how the chip must operate. If they were ever compromised, then the keys on your Spark or Spark 2 chip cannot be changed to mitigate this issue. However, because we are planning to use our FIDO2 applet to verify access to the VivoKey service platform, keys can be easily purged and re-generated at will. Of course, this will mean you will have to plan around a key update by ensuring you have at least two implants registered to your profile so you can retain access to your account after the key purge and re-generation on your Apex (i.e. you should get two Apex implants :slight_smile:).

6 Likes
3

Thanks for the great writeup, both of you :slight_smile: I’m really glad that you plan on supporting asymmetric crypto, as I had basically the same “issues” as @yeka :smiley:

4

Would a spark and an apex work in this regard, or just 2 Apex?

1 Like
5

I would really like an Apex implant and an Apex NFC card for this use case. Think that will be possible?

1 Like
6

It would be nice to keep the 2nd in a locked safe so that both aren’t ever in the same physical location, and are fully air gapped.

1 Like
7

However, because we are planning to use our FIDO2 applet to verify access to the VivoKey service platform, keys can be easily purged and re-generated at will. Of course, this will mean you will have to plan around a key update by ensuring you have at least two implants registered to your profile so you can retain access to your account after the key purge and re-generation on your Apex (i.e. you should get two Apex implants :slight_smile:).

Rather than two apex implants, would it be possible for me to use a physical FIDO2 token in a locked safe?

8

I would say based on this that should be perfectly possible so if an Apex Card or Ring isn’t available for backup this might be a worthy second option, although would allow you to duplicate any other applets on your Apex.

9

We can expect to see fidesmo enabled P71 cards in some form or another soon-ish. Fidesmo is probably working on stuff with their partners this minute.

10

absolutely, but the spark would carry the security issues mentioned above… if you’re ok with that then spark + apex is a great idea.

we are considering a card… or the apexring.com option should be available … eventually :wink:

i don’t know if we are going to support non-vivokey fido2 tokens or not… possibly, but would likely have a lower “trust level”

3 Likes