flipperzero-firmware
flipperzero-firmware copied to clipboard
flipperdevices
NFC: initial support for NFC-F (FeliCa)
What's new
- Added initial support for NFC-F
- Amended NFC structs to accommodate either NFC-A or NFC-F. This can be extended for NFC-B/Calypso
Verification
- I've had only a pre-issued consumer Lite-S card to verify a portion of the code; I plan to later issue my own Lite-S cards with my own keys to implement and verify authentication flow.
- Actual standard FeliCa cards are hard to come by outside of Japan, so it may prove difficult to implement and verify Auth1 and Auth2 command flows, especially when the AES/DES keys are unknown
Checklist (For Reviewer)
- [ ] PR has description of feature/bug or link to Confluence/Jira task
- [ ] Description contains actions to verify feature/bugfix
- [ ] I've built this code, uploaded it to the device and verified feature/bugfix
Actual standard FeliCa cards are hard to come by outside of Japan, so it may prove difficult to implement and verify Auth1 and Auth2 command flows, especially when the AES/DES keys are unknown
Smartcardfocus used to carry them but not anymore. However I found this https://www.amazon.co.jp/gp/product/B009L0R2Z6/ on Amazon Japan. They seem to ship to outside Japan as well. It's a bit pricey except not really (single card price in line with some of the DESFires that I saw) and given that no open source FeliCa stuff really exist I think it might be a good investment.
@dogtopus Unfortunately, they are of little usefulness due to the lack of documentation around authentication, let alone issuance (actually preparing the cards for authenticated uses).
I actually have some cards both newer and old generation just in case, but what would really be nice is some code or software one could analyse for a clean-room implementation, but one price quote is around 230000 JPY. Dumping the firmware of official PaSoRi readers or otherwise experimenting with them are also an option though, as they have a separate command set which maps onto NFC messages
@nullableVoidPtr So if I understand correctly, the problem is less about finding blanks, but more about the fact that we don't know much about FeliCa Standard application management and how to access the encrypted portion of the card, similar to how DESFire was before libfreefare?
(I guess it doesn't really matter for Flipper usage since Flipper never supported managing DESFire applications nor accessing encrypted DESFire applications either even though libfreefare is a thing.
Although I'm kinda curious: Are FeliCa Standard encrypted applications ever used outside transit networks and payment? Even the SDKs Sony provide (probably under NDA but definitely not directly public) support only unencrypted applications.)
So if I understand correctly, the problem is less about finding blanks, but more about the fact that we don't know much about FeliCa Standard
Eh, bit of both; we don't know how to access the cards even if we know the encryption keys, which we don't have and would only know if we issued it in the first place. There may be card printers/issuing machines which attempt to automate this process whose drivers may be useful for an analysis.
Indeed, the point of this (admittedly slightly inactive fork) is just to read as much data. We may be able to issue Lite or Lite-S cards from a Flipper as that process is entirely public and documented.
Are FeliCa Standard encrypted applications ever used outside transit networks and payment? Even the SDKs Sony provide (probably under NDA but definitely not directly public) support only unencrypted applications.)
In practice, basically transport cards which serve as de-facto cash cards. There may be uses of HCE-F or on Android or Mobile FeliCa in general which may fall out of this domain. Other than that mostly more cash cards: WAON, Rakuten Edy, nanaco (which apparently falls under FeliCa Networks' Common Area which is a whole other barrel of fish), and QUICPAY. There is a model of Standard cards which also implement EMV, which is used by SMBC and AEON cards. Some Japanese campuses appear to use something called FCF as a form of identity, which uses FeliCa Standard cards. My Number cards also appear to use FeliCa standard and hence you can file taxes etc. online. Moreover, Blackboard Transact is a identity and payment solution for university campuses, and apparently Fuji Xerox printers uses standard FeliCa cards. There are mentions of something called FeliCa Secure ID, which appears to be solution for authenticating to cloud services. And who knows what FeliCa Plug is used for.
Indeed, the point of this (admittedly slightly inactive fork) is just to read as much data. We may be able to issue Lite or Lite-S cards from a Flipper as that process is entirely public and documented.
IIRC Lite-S is more analogous to Ultralight in terms of application, cost and openness. So read/write/emulate (given that the Flipper NFC hardware supports all the nuances needed to do so) would be great. Besides that, NFC-F IDm emulation would also be a great addition to bring feature parity to Flipper's support of NFC-A.
There is a model of Standard cards which also implement EMV, which is used by SMBC and AEON cards.
(Looks at SmartMX with DESFire partition) Yeah that would be a possibility. ~~Though do we actually have ISO7816 over NFC-F or is it ISO7816 over NFC-A and FeliCa Standard over NFC-F?~~ It's the latter as can be seen here
My Number cards also appear to use FeliCa standard and hence you can file taxes etc. online.
Does eTax actually require Standard features or just IDm is enough? I saw sellers advertise some Lite-S cards being eTax compatible.
Moreover, Blackboard Transact is a identity and payment solution for university campuses
Interesting. I knew that Blackboard Transact uses DESFire. I guess it also supports FeliCa?
There are mentions of something called FeliCa Secure ID, which appears to be solution for authenticating to cloud services.
Looks like it's something supported by hardware (maybe similar to FIDO2) rather than just an application.
I'm in japan and have easy access to felica cards. Tell me what is needed and I am happy to contribute. This is a capability that the hacker scene here really wants, so anything that speeds it up is doable.
I'm in japan and have easy access to felica cards. Tell me what is needed and I am happy to contribute. This is a capability that the hacker scene here really wants, so anything that speeds it up is doable.
It's less about being able to access blank cards but more about lack of public knowledge about how it really works, as the most interesting commands of how to really use a FeliCa (specifically the Standard variant) is largely under NDA and there's not a lot of publicly available software that we could look at to figure these out.
What we need the most is something similar to libfreefare for Mifare DESFire.
@CicadaMikoto If you have a propensity towards reverse engineering, I suppose reader firmware and drivers would be a start? Likewise with any card printers that can do FeliCa issuance.
There are some patents that we can glean some details from, but they appear to mostly relate towards the older DES authentication. One could also procure either one of the SDK Reference Implementations, but it appears to be under license agreements and quite expensive (note: this is ICS-D101/13, whereas the current version appears to be /V15). Additionally, you may get some luck with Japanese marketplaces like Mercari, with one listing for an old version of the SDK here. Be wary of spending too much on blank cards you can find here. I've wasted money on both SD1 and SD2 and got little out of it; there is apparently a transport key that this particular provider hadn't given me, but I'll probably inquire about it in the later months. With the public knowledge on FeliCa standard, we could only implement unauthenticated reads and enumeration and that's it. We can maybe fully implement FeliCa Lite.
I would feel that the white whale for our purposes given all the red tape is a first-issued or second-issued card[^1] with a known authentication key for some known set of areas and services. It doesn't necessarily have to be a "master" key or the system key, as each area and service have their own keys which can be composed into an intermediate key used for the authentication.
[^1]: FeliCa documentation refers to three issuances for a given card: * 0th issue by the manufacturer, setting the unique IDm (manufacturer ID) and the temporary transport key; * 1st issue by the service provider, pre-personalizing the card by setting up the system, allocating areas and services and setting the corresponding mutual authentication keys. * 2nd issue for the cardholder with personalized data.
Hi! Do you need any help with that PR? We would like to add NFC-F support soon, and would be happy to help you if any roadblocks arise.
Hi @Astrrra,
I've admittedly been slow on my PR activity due to work and life, but at the moment the roadblock is working with FeliCa standard cards, which I believe @dogtopus is currently working on, as there are some Japanese SuiCa cards one could work with (and probably parse!). My current plan once I get back to it is to work with self-issued Lite-S cards.
Given what little public information we have, what I think is possible for us to implement is:
- [ ] Lite(-S)
- [x] Unauthenticated reading
- [ ] Authentication
- [ ] Key diversification
- [ ] Writing
- [ ] Issuance(?)
- [ ] Standard
- [ ] Unauthenticated reading
- [ ] Area and Service enumeration
- [ ] Unauthenticated reading
@Astrrra Somewhat a generic Flipper UI programming question: FeliCa Standard has a tree filesystem structure and therefore the current in-memory structure for the dump is also a tree. However when implementing a viewer for the filesystem (think about mf_desfire_data+mf_desfire_app except that mf_desfire_app also needs to handle a nested structure), scene's state is currently quite limited (only a 32-bit integer) and doesn't seem to be enough to contain the states required to navigate the directory tree. Use it as a pointer for some extended bit of data also seems to be hard to track (allocation/free needs to be done on initialization/destruction but I don't think it even supports that, only enter and leave). The current codebase puts the state in Nfc struct which is very ugly. Any suggestions on improving this?
EDIT: never mind figured something out.
Had a question, looking at this reddit comment it seems that emulating NFC-F isn't possible. Is this true?
Had a question, looking at this reddit comment it seems that emulating NFC-F isn't possible. Is this true?
Wait this doesn't really make sense. Cycle-accurate anti-collision makes it a hard real-time task and most hosts won't be able to do it. This would significantly reduce this chip's usefulness on anything other than a very beefy Cortex-R processor. You might as well bitbang at that point.
I don't believe that this won't be handled on the NFC chip itself.
@Astrrra Care to elaborate further?
(~~Looks like there's indeed no special handling for it, though I could be missing something here. Also: can we cheat? The slots are still very wide (in units of 4 MRT (maximum response time for FeliCa, not the terminology in ST25R with the same name) ticks, ~1.2ms or 16384 / fc) and if we can just land somewhere knowing that it's roughly in range we might still be able to pull it off.~~ Self reminder: SENSEF_RES)
The chip itself appears to have API for FeliCa TXRX anyways, and we used it to read cards but maybe they meant how long the timeout the reader waits on a response?
@0chroma Towards emulation though, no; again, red-tape and encryption keys holds us back from emulating most applications like SuiCa and AmusementIC.
(Side note on arcades: DDR/Konami eAmuse readers appears to be a unique case and could probably be fooled as IIRC it can use any arbitrary IDM from a FeliCa (like a FeliCa enabled cell phone) and hence can work with Flipper using basic UID emulation, but this may not needed as there is already NFCA emulation)
but maybe they meant how long the timeout the reader waits on a response?
I think they meant FeliCa user manual section 2.3.5.
Towards emulation though, no; again, red-tape and encryption keys holds us back from emulating most applications like SuiCa and AmusementIC.
eAmusement only checks for IDm for login and IIRC most Amusement IC terminals check for IDm and a public Lite-S block.
Besides that there are apparently smart locks that only look for IDm.
That's plenty of use cases already without the keys.
(Side note on arcades: DDR/Konami eAmuse readers appears to be a unique case and could probably be fooled as IIRC it can use any arbitrary IDM from a FeliCa (like a FeliCa enabled cell phone) and hence can work with Flipper using basic UID emulation, but this may not needed as there is already NFCA emulation)
I did some tests with an iphone to see how mobile emulation works with an on-device pasmo card. The flipper reads it as NFC-A, but the UID changes on each scan (ATQA 0004, SAK: 20). When using my android phone with NFC Tools it reads it as Felica, UID is stable. Not sure if that info helps at all, but it seems like for something like eamuse to work, you'd need to emulate more than just an NFC-A UID.
@0chroma The NFC type detection is broken currently, and if you read modern mobile FeliCa it will read the EMV side instead which would be NFC-A with random UID.
Towards emulation though, no; again, red-tape and encryption keys holds us back from emulating most applications like SuiCa and AmusementIC.
I just assume this includes Aime (the non-Amusement IC side)?
So now #2961 is a thing. Do we need to keep going or FeliCa support will be developed in-house instead?
Hello everyone! Recently we released new NFC stack in #3050. Now FeliCa support is our priority task and we are working on it right now. Unfortunately, previous NFC API was not good enough to add new protocols support. Thanks @nullableVoidPtr for PR and everyone else who took part in discussion. I will close it for now. Stay tuned, soon there will be PRs with FeliCa support.
