Store key on NFC tag that is acceptable to sc_auth?
Is it possible to generate a key and store it on an NFC tag, so that it shows up with "sc_auth hash"? I'm trying to login to OSX using NFC using info from http://support.apple.com/kb/TA24244. The tag I have is a 13.56MHz ISO14443A & NFC Type 2 compliant NTAG216 RFID chipset, and I'm using a ACS ACR122T USB reader. Here's some output from "system.log": 17/01/15 21:04:28,005 com.apple.SecurityServer[71]: reader ACS ACR122U: state changed 16 -> 34 17/01/15 21:04:30,066 com.apple.SecurityServer[71]: token in reader ACS ACR122U cannot be used (error 229) 17/01/15 21:04:33,567 com.apple.SecurityServer[71]: reader ACS ACR122U: state changed 32 -> 18 And from "opensc-tool -l -v": # Detected readers (pcsc) Nr. Card Features Name 0 Yes ACS ACR122U 3b:8f:xx:yy:zz Unsupported card Best regards, Henrik
Hi Henrik,
Le 18 janv. 2015 à 14:07, Henrik Brautaset Aronsen <henrik@synth.no> a écrit :
Is it possible to generate a key and store it on an NFC tag, so that it shows up with "sc_auth hash"?
I'm trying to login to OSX using NFC using info from http://support.apple.com/kb/TA24244. The tag I have is a 13.56MHz ISO14443A & NFC Type 2 compliant NTAG216 RFID chipset, and I'm using a ACS ACR122T USB reader.
Which driver did you use for that? By default, PC/SC Lite don’t know how to talk with cards, you need a driver for that. For what I’ve see, a project is started called ifdnfc to bring this functionality and support NFC card for PKCS11 via OpenSC. But the source code isn’t really active and I don’t know if it work now. Best regards, Yoann Gini
Yoann Gini wrote:
Le 18 janv. 2015 à 14:07, Henrik Brautaset Aronsen<henrik@synth.no> a écrit :
Is it possible to generate a key and store it on an NFC tag, so that it shows up with "sc_auth hash"?
I'm trying to login to OSX using NFC using info from http://support.apple.com/kb/TA24244. The tag I have is a 13.56MHz ISO14443A& NFC Type 2 compliant NTAG216 RFID chipset, and I'm using a ACS ACR122T USB reader.
Which driver did you use for that?
By default, PC/SC Lite don’t know how to talk with cards, you need a driver for that.
For what I’ve see, a project is started called ifdnfc to bring this functionality and support NFC card for PKCS11 via OpenSC.
But the source code isn’t really active and I don’t know if it work now.
Hi Yoann, Thanks for your swift reply! I wasn't aware of the driver requirement, that's good to know. I built pcscd and ifdnfc. ifdnfc-activate connects to pcscd, but says that it "Cannot find a smart card reader". testpcsc says: Testing SCardEstablishContext : Command successful. Testing SCardIsValidContext : Command successful. Testing SCardIsValidContext : Invalid handle. (don't panic) Testing SCardListReaderGroups : Command successful. Group 01: SCard$DefaultReaders Testing SCardFreeMemory : Command successful. Testing SCardListReaders : Cannot find a smart card reader. (don't panic) Testing SCardGetStatusChange Please insert a working reader : The stock OSX version of pcsctest finds the reader just fine: $ /usr/bin/pcsctest Testing SCardEstablishContext : Command successful. Testing SCardGetStatusChange Please insert a working reader : Command successful. Testing SCardListReaders : Command successful. Reader 01: ACS ACR122U Maybe I need ifdnfc to talk to /System/Library/Frameworks/PCSC.framework/Versions/A/XPCServices/com.apple.ctkpcscd.xpc/Contents/MacOS/com.apple.ctkpcscd instead of my self-built pcscd? Best regards, Henrik
Hi,
Le 20 janv. 2015 à 20:51, Henrik Brautaset Aronsen <henrik@synth.no> a écrit :
The stock OSX version of pcsctest finds the reader just fine:
$ /usr/bin/pcsctest
Testing SCardEstablishContext : Command successful. Testing SCardGetStatusChange Please insert a working reader : Command successful. Testing SCardListReaders : Command successful. Reader 01: ACS ACR122U
If the built in pc/sc detect the reader, it’s a good start. It means it’s working on the reader side. Now you need to look at your cards. Which NFC chipset do you use? And with which TockenD module? Don’t forget that SmartCards aren’t just storage cards, you have a microprocessor and a small system on it to store yours keys and handle the secure communication. Best regards, Yoann Gini
Yoann Gini wrote:
Le 20 janv. 2015 à 20:51, Henrik Brautaset Aronsen <henrik@synth.no <mailto:henrik@synth.no>> a écrit :
The stock OSX version of pcsctest finds the reader just fine:
$ /usr/bin/pcsctest
Testing SCardEstablishContext : Command successful. Testing SCardGetStatusChange Please insert a working reader : Command successful. Testing SCardListReaders : Command successful. Reader 01: ACS ACR122U
If the built in pc/sc detect the reader, it’s a good start. It means it’s working on the reader side.
Now you need to look at your cards. Which NFC chipset do you use? And with which TockenD module?
The reader says: $ /usr/bin/pcsctest ... Reader 01: ACS ACR122U Waiting for card insertion : Command successful. Testing SCardConnect : Command successful. Testing SCardStatus : Command successful. Current Reader Name : ACS ACR122U Current Reader State : 0x54 Current Reader Protocol : 0x0 Current Reader ATR Size : 20 (0x14) Current Reader ATR Value : 3B xx xx xx The chipset is is a 13.56MHz ISO14443A & NFC Type 2 compliant NTAG216 RFID chipset. I haven't selected any TokenD module, mostly because I don't know how to. Any feedback on this is greatly appreciated.
Don’t forget that SmartCards aren’t just storage cards, you have a microprocessor and a small system on it to store yours keys and handle the secure communication.
I realize this. But according to http://support.apple.com/kb/TA24244 it seems that I can get away with storing a key on the NFC that is accessible with "sc_auth hash". Does that sound reasonable? Cheers, Henrik
Henrik, Your email messages are all referencing the support of hardware (NFC readers and the hardware of the smartcard recognition of the electronics of the smart card), but not the Applet on the card. Support for communicating correctly with the Applet loaded onto a card is done by a corresponding TokenD. You do not select the card to use a particular Tokend, but rather you must have installed a TokenD that supports the Applet loaded on the card. There are many Applet specifications out there, so you need to know what your card is using and install the appropriate TokenD. Whether you access the card with a generic CCID USB-based smart card reader or a USB-NFC based reader is not the problem you are facing. Once your particular smart card type is supported by an installed Tokend, then ALL services access and use the card as a dynamic keychain - via keychain services. No application or service needs to know it is a smart card and simply uses the standard keychain / Sec… APIs available on OS X. So yes, once you have a supporting Tokend, you could use sc_auth to assign a card to an account for login, but realize that is not the normal method for Smart Card Login on OS X. You are much better off using the standard of PKINT which leverages both PKI and your Microsoft AD’s KDC. So, before any of us can help you further, we need to know and understand what Card Type (applet loaded on the card) you are using or want to use on your system. - Shawn _______________________________________________________________________ Shawn Geddis Security and Certifications Engineer, Apple (geddis@apple.com <mailto:geddis@apple.com>) SCAP-On-Apple Project/Dev Lead: (SCAP-On-Apple.MacOSForge.Org <http://scap-on-apple.macosforge.org/>) SmartCardServices Project/Dev Lead: (SmartCardServices.MacOSForge.Org <http://smartcardservices.macosforge.org/>) _______________________________________________________________________
On Jan 24, 2015, at 4:53 AM, Henrik Brautaset Aronsen <henrik@synth.no> wrote:
Yoann Gini wrote:
Le 20 janv. 2015 à 20:51, Henrik Brautaset Aronsen <henrik@synth.no <mailto:henrik@synth.no>> a écrit :
The stock OSX version of pcsctest finds the reader just fine:
$ /usr/bin/pcsctest
Testing SCardEstablishContext : Command successful. Testing SCardGetStatusChange Please insert a working reader : Command successful. Testing SCardListReaders : Command successful. Reader 01: ACS ACR122U
If the built in pc/sc detect the reader, it’s a good start. It means it’s working on the reader side.
Now you need to look at your cards. Which NFC chipset do you use? And with which TockenD module?
The reader says:
$ /usr/bin/pcsctest ... Reader 01: ACS ACR122U Waiting for card insertion : Command successful. Testing SCardConnect : Command successful. Testing SCardStatus : Command successful. Current Reader Name : ACS ACR122U Current Reader State : 0x54 Current Reader Protocol : 0x0 Current Reader ATR Size : 20 (0x14) Current Reader ATR Value : 3B xx xx xx
The chipset is is a 13.56MHz ISO14443A & NFC Type 2 compliant NTAG216 RFID chipset. I haven't selected any TokenD module, mostly because I don't know how to. Any feedback on this is greatly appreciated.
Don’t forget that SmartCards aren’t just storage cards, you have a microprocessor and a small system on it to store yours keys and handle the secure communication.
I realize this. But according to http://support.apple.com/kb/TA24244 <http://support.apple.com/kb/TA24244> it seems that I can get away with storing a key on the NFC that is accessible with "sc_auth hash". Does that sound reasonable?
Cheers, Henrik _______________________________________________ SmartcardServices-Users mailing list SmartcardServices-Users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/smartcardservices-users
On 24 Jan 2015, at 23:54, Shawn Geddis <geddis@icloud.com> wrote:
Your email messages are all referencing the support of hardware (NFC readers and the hardware of the smartcard recognition of the electronics of the smart card), but not the Applet on the card.
This is just a rewritable NFC tag with about 800 bytes of rewriteable memory [1]. It's not interfaced with a smartcard, so I guess an applet is not available in my case.
Once your particular smart card type is supported by an installed Tokend, then ALL services access and use the card as a dynamic keychain - via keychain services. No application or service needs to know it is a smart card and simply uses the standard keychain / Sec… APIs available on OS X. So yes, once you have a supporting Tokend, you could use sc_auth to assign a card to an account for login, but realize that is not the normal method for Smart Card Login on OS X. You are much better off using the standard of PKINT which leverages both PKI and your Microsoft AD’s KDC.
I opted for the simple hash authentication mechanism, since it looked like the simplest way to achieve my goal. It would just require a field on my user's authentication_authority property containing the hash.
So, before any of us can help you further, we need to know and understand what Card Type (applet loaded on the card) you are using or want to use on your system.
I really appreciate all the help I'm receiving! But maybe logging into OSX with an NFC tag is not achievable? Henrik [1] http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf
On Jan 25, 2015, at 8:08 AM, Henrik Brautaset Aronsen <henrik@synth.no <mailto:henrik@synth.no>> wrote: On 24 Jan 2015, at 23:54, Shawn Geddis <geddis@icloud.com <mailto:geddis@icloud.com>> wrote:
Your email messages are all referencing the support of hardware (NFC readers and the hardware of the smartcard recognition of the electronics of the smart card), but not the Applet on the card.
This is just a rewritable NFC tag with about 800 bytes of rewriteable memory [1]. It's not interfaced with a smartcard, so I guess an applet is not available in my case.
Once your particular smart card type is supported by an installed Tokend, then ALL services access and use the card as a dynamic keychain - via keychain services. No application or service needs to know it is a smart card and simply uses the standard keychain / Sec… APIs available on OS X. So yes, once you have a supporting Tokend, you could use sc_auth to assign a card to an account for login, but realize that is not the normal method for Smart Card Login on OS X. You are much better off using the standard of PKINT which leverages both PKI and your Microsoft AD’s KDC.
I opted for the simple hash authentication mechanism, since it looked like the simplest way to achieve my goal. It would just require a field on my user's authentication_authority property containing the hash.
So, before any of us can help you further, we need to know and understand what Card Type (applet loaded on the card) you are using or want to use on your system.
I really appreciate all the help I'm receiving! But maybe logging into OSX with an NFC tag is not achievable?
Henrik
[1] http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf <http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf>
Henrik,
This is just a rewritable NFC tag with about 800 bytes of rewriteable memory [1]. It's not interfaced with a smartcard, so I guess an applet is not available in my case.
A TokenD can be written to communicate with just about any type of device or technology. Sorry if I implied otherwise. My reference to Applet was because the vast majority of Smart Cards/Readers in use, particularly on OS X, are those used for PKI and are applet based. Any developer, however, can create a TokenD that communicates with any technology — an NFC tag, an HSM, a key FOB, etc… Looking at content from your original email message: 17/01/15 21:04:28,005 com.apple.SecurityServer[71]: reader ACS ACR122U: state changed 16 -> 34 17/01/15 21:04:30,066 com.apple.SecurityServer[71]: token in reader ACS ACR122U cannot be used (error 229) 17/01/15 21:04:33,567 com.apple.SecurityServer[71]: reader ACS ACR122U: state changed 32 -> 18 The second line shows that no currently installed TokenD responded to the SmartCardServices layer that it could recognize and communicate with the current token recognized after the event “token Insertion” (card insertion) took place. If you develop a TokenD to respond with success after probing the Token, you would then have a TokenD which would remain loaded until the “token removal” (card removal) event was recognized. If you are going to be doing the development yourself or you are helping someone else do the development, you might want to look at the source code in the repository for say "PIV” (for PIV.tokend) inside the tokend Xcode Project and start with the probe function to understand how the "score” determines which TokenD “wins” and remains loaded/communicating with the ‘token’. Please keep in mind the open source licensing requirements. It is possible to do what you want *IF* you develop or have someone else develop the corresponding TokenD to support the devices (ie. NXP NTAG) you wish to use. Hope this helps to explain the environment better and give you guidance as to how to proceed. - Shawn _______________________________________________________________________ Shawn Geddis Security and Certifications Engineer, Apple (geddis@apple.com <mailto:geddis@apple.com>) SCAP-On-Apple Project/Dev Lead: (SCAP-On-Apple.MacOSForge.Org <http://scap-on-apple.macosforge.org/>) SmartCardServices Project/Dev Lead: (SmartCardServices.MacOSForge.Org <http://smartcardservices.macosforge.org/>) _______________________________________________________________________
On 25 Jan 2015, at 21:34, Shawn Geddis <geddis@icloud.com> wrote:
On Jan 25, 2015, at 8:08 AM, Henrik Brautaset Aronsen <henrik@synth.no> wrote:
This is just a rewritable NFC tag with about 800 bytes of rewriteable memory [1]. It's not interfaced with a smartcard, so I guess an applet is not available in my case.
A TokenD can be written to communicate with just about any type of device or technology. Sorry if I implied otherwise. My reference to Applet was because the vast majority of Smart Cards/Readers in use, particularly on OS X, are those used for PKI and are applet based. Any developer, however, can create a TokenD that communicates with any technology — an NFC tag, an HSM, a key FOB, etc…
I see! Thanks for insight.
Looking at content from your original email message: 17/01/15 21:04:28,005 com.apple.SecurityServer[71]: reader ACS ACR122U: state changed 16 -> 34 17/01/15 21:04:30,066 com.apple.SecurityServer[71]: token in reader ACS ACR122U cannot be used (error 229) 17/01/15 21:04:33,567 com.apple.SecurityServer[71]: reader ACS ACR122U: state changed 32 -> 18
The second line shows that no currently installed TokenD responded to the SmartCardServices layer that it could recognize and communicate with the current token recognized after the event “token Insertion” (card insertion) took place. If you develop a TokenD to respond with success after probing the Token, you would then have a TokenD which would remain loaded until the “token removal” (card removal) event was recognized.
OK, so a TokenD is required to get me any further? Got it.
If you are going to be doing the development yourself or you are helping someone else do the development, you might want to look at the source code in the repository for say "PIV” (for PIV.tokend) inside the tokend Xcode Project and start with the probe function to understand how the "score” determines which TokenD “wins” and remains loaded/communicating with the ‘token’. Please keep in mind the open source licensing requirements.
That's a good start, thanks.
It is possible to do what you want *IF* you develop or have someone else develop the corresponding TokenD to support the devices (ie. NXP NTAG) you wish to use.
Hope this helps to explain the environment better and give you guidance as to how to proceed.
It certainly does. So, do you reckon I need libnfc [1] or ifdnfc [2] at all? I've been pointed to those by other sources. Henrik [1] http://nfc-tools.org/index.php?title=Libnfc [2] http://nfc-tools.org/index.php?title=Ifdnfc
On 21 Jan 2015, at 12:14, Yoann Gini <yoann.gini@gmail.com> wrote:
If the built in pc/sc detect the reader, it’s a good start. It means it’s working on the reader side.
Now you need to look at your cards. Which NFC chipset do you use? And with which TockenD module?
My chipset is NXP NTAG [1], and it seems I have to develop a TokenD module for it. If I don't find anyone who's already done it, that is. C++ isn't my strongest language, to say the least :)
Don’t forget that SmartCards aren’t just storage cards, you have a microprocessor and a small system on it to store yours keys and handle the secure communication.
Yeah, it seems I have to get past that, since I only want to use a tag and not a full smartcard. Thanks for your input! Henrik [1] http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf
I don't see anything in the NTAG data sheet that leads me to believe that a login solution based on it would be secure against eavesdropping, cloning, and replay attacks. We used to call these "barking bar codes" and for security sensitive operations (such as authentication) they are not safe. If you're OK with that, well, it's your headache not mine. But I'd never buy one. Password ACLs controlling memory write operations is not the same as what happens in a smart card. For secure use, you need--at a minimum--an IC capable of computing a response to a challenge. Ideally you do this by performing a cryptographic operation using a secret unique to the IC. In NXP's offerings (quickly poking around their offerings), that probably puts you in the SmartMX line, but you'd need a platform that integrates that IC with and NFC controller (e.g., NXP's PT501)--something like the NXP MIFARE platform. -- T
-----Original Message----- From: smartcardservices-users-bounces@lists.macosforge.org [mailto:smartcardservices-users-bounces@lists.macosforge.org] On Behalf Of Henrik Brautaset Aronsen Sent: Monday, February 02, 2015 1:42 PM To: Yoann Gini Cc: smartcardservices-users@lists.macosforge.org Subject: Re: [SmartcardServices-Users] Store key on NFC tag that is acceptable to sc_auth?
On 21 Jan 2015, at 12:14, Yoann Gini <yoann.gini@gmail.com> wrote:
If the built in pc/sc detect the reader, it’s a good start. It means it’s working
on the reader side.
Now you need to look at your cards. Which NFC chipset do you use? And
with which TockenD module?
My chipset is NXP NTAG [1], and it seems I have to develop a TokenD module for it. If I don't find anyone who's already done it, that is. C++ isn't my strongest language, to say the least :)
Don’t forget that SmartCards aren’t just storage cards, you have a microprocessor and a small system on it to store yours keys and handle the secure communication.
Yeah, it seems I have to get past that, since I only want to use a tag and not a full smartcard.
Thanks for your input!
Henrik
[1] http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf
_______________________________________________ SmartcardServices-Users mailing list SmartcardServices-Users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/smartcardservices-users
On 02 Feb 2015, at 21:05, Miller, Timothy J. <tmiller@mitre.org> wrote:
I don't see anything in the NTAG data sheet that leads me to believe that a login solution based on it would be secure against eavesdropping, cloning, and replay attacks. We used to call these "barking bar codes" and for security sensitive operations (such as authentication) they are not safe.
If you're OK with that, well, it's your headache not mine. But I'd never buy one.
Password ACLs controlling memory write operations is not the same as what happens in a smart card. For secure use, you need--at a minimum--an IC capable of computing a response to a challenge. Ideally you do this by performing a cryptographic operation using a secret unique to the IC. In NXP's offerings (quickly poking around their offerings), that probably puts you in the SmartMX line, but you'd need a platform that integrates that IC with and NFC controller (e.g., NXP's PT501)--something like the NXP MIFARE platform.
Hi Timothy, Thanks for the input! I'm totally OK with the security implications. I'm not doing this for a commercial product, it's merely a hobby project of mine. If I could get it to just check the NFC ID, that would be perfect. Cheers, Henrik
Henrik, You could write a basic TokenD then which just populates one item as a Key which would be set to the value you get from the ID of that tag. Then Your Apps could use that Key (Tag ID). Keep in mind Tim’s comments if you think about taking this beyond tinkering. - Shawn _____________________________________________________________________ Shawn Geddis geddis at {Mac | Me | iCloud}.com Security and Certifications Engineer, Apple geddis at apple.com Smart Card Services Project/Dev Lead: Project Wiki: [SmartCardServices.MacOSFforge.Org <http://smartcardservices.macosfforge.org/>] Mailing Lists: [Lists.MacOSForge.Org/mailman/listinfo <http://lists.macosforge.org/mailman/listinfo>] SCS Contact: [scs-cotact@macosforge.org <mailto:scs-cotact@macosforge.org>] SCS Admin: [scs-admin@macosforge.org <mailto:scs-admin@macosforge.org>] _____________________________________________________________________
On Feb 2, 2015, at 12:16 PM, Henrik Brautaset Aronsen <henrik@synth.no> wrote:
On 02 Feb 2015, at 21:05, Miller, Timothy J. <tmiller@mitre.org> wrote:
I don't see anything in the NTAG data sheet that leads me to believe that a login solution based on it would be secure against eavesdropping, cloning, and replay attacks. We used to call these "barking bar codes" and for security sensitive operations (such as authentication) they are not safe.
If you're OK with that, well, it's your headache not mine. But I'd never buy one.
Password ACLs controlling memory write operations is not the same as what happens in a smart card. For secure use, you need--at a minimum--an IC capable of computing a response to a challenge. Ideally you do this by performing a cryptographic operation using a secret unique to the IC. In NXP's offerings (quickly poking around their offerings), that probably puts you in the SmartMX line, but you'd need a platform that integrates that IC with and NFC controller (e.g., NXP's PT501)--something like the NXP MIFARE platform.
Hi Timothy,
Thanks for the input! I'm totally OK with the security implications. I'm not doing this for a commercial product, it's merely a hobby project of mine. If I could get it to just check the NFC ID, that would be perfect.
Cheers, Henrik
FWIW, do you know about Knock? Uses BTLE to pair to an iPhone; physical control of both allows you to log into the Mac. Sorta similar to Chrome OS Smart Unlock with Android 5.0. I'm not endorsing Knock (or Smart Unlock) as safe--and by most accounts Knock has some issues, esp. after a reboot--but IMHO pairing with a phone is probably safer than using an NFC tag, and the smart phone is certainly capable enough to emulate a smart card. -- T
-----Original Message----- From: Henrik Brautaset Aronsen [mailto:henrik.aronsen@gmail.com] On Behalf Of Henrik Brautaset Aronsen Sent: Monday, February 02, 2015 2:17 PM To: Miller, Timothy J. Cc: Yoann Gini; smartcardservices-users@lists.macosforge.org Subject: Re: [SmartcardServices-Users] Store key on NFC tag that is acceptable to sc_auth?
On 02 Feb 2015, at 21:05, Miller, Timothy J. <tmiller@mitre.org> wrote:
I don't see anything in the NTAG data sheet that leads me to believe that a
login solution based on it would be secure against eavesdropping, cloning, and replay attacks. We used to call these "barking bar codes" and for security sensitive operations (such as authentication) they are not safe.
If you're OK with that, well, it's your headache not mine. But I'd never buy
one.
Password ACLs controlling memory write operations is not the same as
what happens in a smart card. For secure use, you need--at a minimum--an IC capable of computing a response to a challenge. Ideally you do this by performing a cryptographic operation using a secret unique to the IC. In NXP's offerings (quickly poking around their offerings), that probably puts you in the SmartMX line, but you'd need a platform that integrates that IC with and NFC controller (e.g., NXP's PT501)--something like the NXP MIFARE platform.
Hi Timothy,
Thanks for the input! I'm totally OK with the security implications. I'm not doing this for a commercial product, it's merely a hobby project of mine. If I could get it to just check the NFC ID, that would be perfect.
Cheers, Henrik
On 02 Feb 2015, at 21:27, Miller, Timothy J. <tmiller@mitre.org> wrote:
FWIW, do you know about Knock? Uses BTLE to pair to an iPhone; physical control of both allows you to log into the Mac. Sorta similar to Chrome OS Smart Unlock with Android 5.0.
Yup. Quite fun project. I'm an Android guy myself, though, so I'd have to wait until they release a version for my phone.
I'm not endorsing Knock (or Smart Unlock) as safe--and by most accounts Knock has some issues, esp. after a reboot--but IMHO pairing with a phone is probably safer than using an NFC tag, and the smart phone is certainly capable enough to emulate a smart card.
The thing is, I have an NFC implant. It would have been fun to make use of it :) Henrik
participants (4)
-
Henrik Brautaset Aronsen
-
Miller, Timothy J.
-
Shawn Geddis
-
Yoann Gini