I am interested in buying the VivoKey Spark. After some research I realized that this implant has to hit VivoKey servers before executing the URL commmand. My question Is why? Why does it have to hit the VivoKey servers? It also brings up the problem of surveillance. Vivokey is keeping a record of every time the tag is scanned. This makes me uncomfortable because in the privacy policy of VivoKey it states “However, non-personally identifiable visitor information may be provided to other parties for marketing, advertising, or other uses.”. Maybe I am missing something here but the benefit to me as a end user seems less than what VivoKey will gain from the data they are harvesting from me. What are some uses of the VivoKey that does not require proprietary software/logging?
I myself am equipped with a Vivokey.
Personally I do not put anything too personal on my implants, especially shortcuts internet.
I believe that unless you hack Vivokeys servers, it’s almost impossible to steal or leave your data to anyone.
In addition, there are several options including blocking to other NFC users, in itself, unless you scan your implant directly or hack the Vivokeys servers, your information will remain personal, especially if you decide to block them to others.
Hey @Chop
Those are some valid concerns. At this point in it’s development, the Spark only has a handful of uses. It has a unique identifier (UID) that can be registered in an access control system, just like the other NFC tags. You can also configure the redirect URL using the VivoKey app. It might seem like you’re not getting much out of it at the moment, but it’s certainly not a ploy to acquire data. The platform is growing with the eventual goal of supporting payments. If you’ve checked out the forums, you know that’s a HUGE hassle because of the way EMV operates.
The other NFC tag implants available on the site are Type 2 or Type 4, and use simple NDEF records that can be modified by the user (or anyone). Amal and several people on these forums have determined that truly securing those tags is next to impossible. The VivoKey Spark is a different type of tag (ICODE ISO15693 NFC Type 5 compliant chip.) See this thread for more info.
The reason the Spark always communicates with the VivoKey servers whenever it is scanned, is to authenticate that it is truly the specific Spark that it claims it is. The local tag is unable to protect it’s private security keys from malicious actors. The Spark is pre-configured to authenticate with VivoKey’s servers, so it can prove its identity without exposing it’s vulnerabilities.
The Flex One is another VivoKey product that is currently in private beta. It can be used to authenticate the user’s identity, like the Spark. It can also perform cryptographic functions internally and generate it’s own keys (no need to sync with the VivoKey servers.) This functionality will hopefully allow us to endear ourselves to the vengeful EMV cabal, and enable implanted payments. The VivoKey Spark will be able to piggyback on that success and hopefully allow payments with minimal effort or discomfort for the user.
If you’re talking about the privacy policy here:
https://www.vivokey.com/privacy
It says:
Do we disclose any information to outside parties?
We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information. This does not include trusted third parties who assist us in operating our site, conducting our business, or servicing you, so long as those parties agree to keep this information confidential. We may also release your information when we believe release is appropriate to comply with the law, enforce our site policies, or protect ours or others rights, property, or safety. However, non-personally identifiable visitor information may be provided to other parties for marketing, advertising, or other uses
It seems to be covering the possibility that VivoKey will need to share some basic statistics on number of users with EMV and other groups to gain traction. Also, disclaimers like this are a goodwill gesture to users of the platform. Instead of just saying “we have 10 thousand users and growing!” and potentially alienating security concious users like us who don’t want to be counted, VivoKey is up front about it. Running a startup is hard, and you need every resource you can get to prove your validity, without taking advantage of your user base.
The goal for VivoKey Spark is that it’s plug-and-play, i.e. no programming things to the implant. We had explored the idea of allowing the content on the chip to be changed, but ran into two problems;
-
we were unable to allow the memory blocks to be updatable without also allowing the AES cryptographic keys to also be put into a state that had security issues… so we opted to lock it all down.
-
we began to explore functional application features that now rely on that URL NDEF record to be on the chip so we can hook scan actions and do the other things we’re planning… so it has become a part of the feature platform to require that unique URL to be on each Spark chip.
We do process the scan behavior as set by you, but at the moment we do not keep scan action logs longer than 30 days, which is long enough to address any support concerns that may arise.
To be fair, our DESFire based implants like the flexDF, flexDF2, and xDF2 are all capable of operating secure file and AID storage operations using 3DES or AES (depending on the product), but these features are definitely not user friendly and we have no plans on leveraging those features in any future Dangerous Things apps or offerings… so if you want security for your personal applications, you will need to read the chipset datasheets for those products and code your own. The point for VivoKey is again, to be plug-and-play, but at the same time be secure and easy to integrate into web standard services and apps via our web standard APIs.
This is sort of correct. When any random person scans a VivoKey with no specific NFC app up, a browser is launched to that chip’s specific VivoKey URL, and then the VivoKey server does whatever the VivoKey member has set for that chip’s “scan behavior”… which means it can forward the person on to another URL, show the VivoKey member’s profile information, or just show a “private” placeholder (i.e. do nothing). The real magic happens when we begin integrating VivoKey chip scan services with 3rd parties and API plugins. In these scenarios, we leverage the crypto-secure aspect of the VivoKey Spark chip to approve an action like an account authentication or a transaction authorization. For example, we have a WordPress plugin coming soon which will allow the VivoKey members with WordPress blogs to secure their blog authentication with VivoKey instead of a username and password. Once configured, when you wish to log into your WordPress back-end, a push notification will be sent to your registered phone or phones, asking you to scan your VivoKey to log in to WordPress. Scan your chip on your phone and you are logged into WordPress. This is where the cryptographic functions come into play.