| 00:43.28 | DocScrutinizer05 | Oksana: the (sidnote) fineprint is only needed in German, it's basically for the tax office only |
| 00:44.09 | DocScrutinizer05 | it's the formal legalese blabla saying same thing we always said |
| 00:45.18 | DocScrutinizer05 | and when you don't understand it in German language then chances are rather minimal that you could make any use of it in whatever way, even when we translated it to english, russian, chinese, hindi, dunnowaht, and inuktitut |
| 00:45.39 | Oksana | Alright, so there is a payWave-enabled merchant, an NFC-including phone, with an NFC-enabled SIM. Does the user need any additional banking app on the phone? Or does the signal go directly from NFC chip to SIM and back, with any interaction with main computer? And NFC chip, gaining power from 'merchant', can use it to do a transaction even when battery is at 0 and phone is switched off? |
| 00:46.49 | DocScrutinizer05 | aiui nope, the card amd HFC tansceiver work even without APE at all, even without battery insrted to device |
| 00:47.42 | DocScrutinizer05 | it's just a glorified Proximity Contact Communication Card(?) |
| 00:47.45 | DocScrutinizer05 | PCC |
| 00:48.07 | DocScrutinizer05 | you got exactly same stuff in every visa electron I guess |
| 00:49.50 | DocScrutinizer05 | what you need to do however, once, per app or per driver: configure the PN544 chip so it has PCC emulation enabled |
| 00:50.36 | DocScrutinizer05 | then you can remove the battery from Neo900 and use it as the fattest heaviest NFC smartcard ever |
| 00:59.51 | DocScrutinizer05 | PICC, Proximity Interface Coupling Card |
| 01:03.01 | Oksana | Or a wallet of smart-cards? What is needed to emulate a smart-card? To emulate a Visa card, you usually use SIM card with Visa's app on it (so-called NFC-enabled SIM). To emulate a transport-card (MIFARE DESFire EV1), or an ID card, or a passport... What is required?.. |
| 01:04.21 | DocScrutinizer05 | aiui PN544 can do "on-board" Mifare |
| 01:04.50 | DocScrutinizer05 | so all that's really required is the secret key that gets challenged, I guess |
| 01:05.02 | DocScrutinizer05 | just like with any SIM |
| 01:05.14 | DocScrutinizer05 | (on SIM's primary usage) |
| 01:05.44 | DocScrutinizer05 | the problem is: nobody will give you this secret key since it would allow card cloning |
| 01:05.50 | DocScrutinizer05 | again like with SIM |
| 01:06.38 | DocScrutinizer05 | maybe some day somebody hacks Visa Electron secure element, and finds a way to read out the secret key |
| 01:06.40 | DocScrutinizer05 | again like with SIM |
| 01:08.01 | DocScrutinizer05 | but take all that with a grain of salt, I never looked into all that Visa wave etc stuff, nor into NFC too closely. It's all just educated guesses |
| 01:08.47 | DocScrutinizer05 | but given the usecase scenario and architecture it#s quite obvious what's going on |
| 01:09.19 | DocScrutinizer05 | it's simply a wireless smartcard implementation |
| 01:17.25 | Oksana | Hmm... Theoretically, you could put many SIM cards into one phone, and switch between them depending on which one you currently wish to use. But it would require further miniaturisation of SIM card. Or alternatively, SecureCard would become dissociated from SIM card, and user would ask bank, transport-authority, any organisation, to add their secret key into the SecureCard, so that user... |
| 01:17.27 | Oksana | ...would be able to see list of keys, and choose one of them depending on current NFC-application. Because truly, there is no need to put BankCardAndSuch into cellular modem. It was just the most universal platform, with the least fragmentation. And 'the most secure' one. |
| 01:19.03 | DocScrutinizer05 | first one is what I was pondering when I mentioned synergy from dual-SIM design in Neo900 |
| 01:20.30 | DocScrutinizer05 | for the latter think of it like a batch of Visa Electorn and other NFC cards. The reader identifies the application and only the "correct" card will answer. Same should be possible on a SIM card with detached transceiver like PN544 |
| 01:21.24 | DocScrutinizer05 | as well as a universal smartcard that can inherit/lern multiple identities |
| 01:21.29 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 01:22.07 | DocScrutinizer05 | you just need something that's kinda certified so the service providers can trust in it |
| 01:22.41 | DocScrutinizer05 | that's why SIM is used and not some EEPROM or flash storage on device, in case of NFC enabled phones |
| 01:23.42 | DocScrutinizer05 | all the security in a secure card/element comes from its resistence against RE and readout of the data |
| 01:24.21 | DocScrutinizer05 | if you could read out a SIM easily, you could create a zillion clones and sell them |
| 01:24.56 | DocScrutinizer05 | all sort of indentity spoofing and theft would be wide open |
| 01:25.36 | DocScrutinizer05 | how much worse this would be with a payment card |
| 01:27.00 | DocScrutinizer05 | thus the only thing you can read out from the card is the response to a challenge, and this has to fit with the key in POS-reader |
| 01:27.18 | DocScrutinizer05 | but you never can read out the key of the secure element |
| 01:28.01 | DocScrutinizer05 | there's however no reason why a secure element can't have multiple such keys and pick the one that matches the received challenge |
| 01:29.07 | DocScrutinizer05 | I dunno if there are protocols that allow writing a signed encrypted new key to a card and the card decodes the encryption with a secret master key or somesuch |
| 01:30.23 | DocScrutinizer05 | when Visa, Diners, Maestro etc all accept thatmaster key and the card hardware as safe, they could program your new application into *your* multi-purpose smartcard even remotely |
| 01:31.27 | DocScrutinizer05 | of course your local secret master key would have to be unique then, so the transferred credentials could only get decryped on *your* card and nothing else |
| 01:32.41 | Oksana | So... If dual-SIM was more common, people could have one not-bank-SIM and one bank-SIM, already. The problem is to persuade some organisation to create not-necessarily-cellular multi-purpose UICC, into which the banks and other organisations would trust. |
| 01:33.37 | DocScrutinizer05 | yes. And you need a phone that connects secondary SIM slot to the NFC transceiver, not the primary which is used by modem |
| 01:34.09 | DocScrutinizer05 | or you have a mux that selects which of both SIM to connect to MFC |
| 01:34.15 | DocScrutinizer05 | which is what I pondered |
| 01:34.29 | DocScrutinizer05 | s/MFC/NFC/ |
| 01:35.49 | Oksana | But knowing that dual-SIM and not-cellular UICC are not common, the most likely scenario is that cellular operators will then partner with transport-authorities and such, so that all the eggs are in one basket, and you can only hope that some kind of remote cellular-attack does not read-or-modify the 'secure' part of the SIM. |
| 01:36.07 | DocScrutinizer05 | again, I heard Apple plans to enetr that playground. I'm curious what the will come up with |
| 01:37.06 | DocScrutinizer05 | SIM are relatively thotoughly tested for security against any such attack |
| 01:37.43 | DocScrutinizer05 | and yes, I think phone carriers cooperating with public transport is one of the most common usecases for NFC already |
| 01:41.57 | DocScrutinizer05 | they even tried pay-per-mile where a infrastructure monitors and accounts where you enter and where you leave tram. But since they cannot guarantee that they will get a readout when you leave the tram, they have to implement fallback solutions and those beg to get abused for fraud. Enter tram, on next station pack your phone into an alu bag -> ride for free from now on |
| 01:43.39 | wpwrak | there's a very simple solution to this: charge the maximum on entry, return what you didn't use on exit |
| 01:44.00 | DocScrutinizer05 | or other extreme: you walk by a tram stopping at station. The NFC reader "looks out the window" and reads your NFC ticket. Now they think you ride that train at least until end of day |
| 01:44.58 | DocScrutinizer05 | wpwrak: requiring that users book out at a person-separator when leaving the train is a nogo |
| 01:45.21 | DocScrutinizer05 | you're better of with paper tickets then |
| 01:45.26 | DocScrutinizer05 | off* |
| 01:47.48 | wpwrak | what would a person-separator do ? and why would you need it ? |
| 01:47.50 | DocScrutinizer05 | and then comes duty of evidence. Whose fault is it when the system thhinks you used that train to drive around whole town 3 times in a row, while you are sure you only had a trip to next station? |
| 01:47.55 | Oksana | Book out when leaving the train? That's how it works here. With MIFARE DESFire EV1. At least, it is better than having your paper ticket stuck inside the ticket machine. |
| 01:47.59 | wpwrak | you just check who exits the area |
| 01:48.32 | wpwrak | give some feedback at a turnstile. if someone's card doesn't "check out", they can go complain at a counter (or pay the max fare) |
| 01:48.53 | DocScrutinizer05 | wpwrak: please! that's exactly the point that you never know when you missed to "cjeck someone leaving the area" |
| 01:49.18 | wpwrak | DocScrutinizer05: make the check-out explicit, with feedback |
| 01:49.34 | DocScrutinizer05 | turnstile == person separator |
| 01:49.49 | Oksana | It takes some time for the card-reader to read the card, and approve the exit. The approval is accompanied by audible sound, blinking LED on the reader and card balance on screen of the reader. |
| 01:49.49 | wpwrak | well, so be it :) that's what we have here all over the place. it works ;-) |
| 01:50.42 | DocScrutinizer05 | can't be done here, I can't imagine how to build those things into tram wagons |
| 01:50.52 | DocScrutinizer05 | even into buses |
| 01:51.34 | DocScrutinizer05 | we're not talking subway here, where you are in a "cave" with only 2 exits |
| 01:51.35 | wpwrak | ah yes, here it's trains and subways. subway without checkout so far, only checkin. but the turnstiles are there both ways. |
| 01:52.47 | DocScrutinizer05 | they tried to implement something for trams I said |
| 01:53.00 | DocScrutinizer05 | and for buses, I may add |
| 01:53.07 | Oksana | If you do not check out properly, you get maximum fare. And the readers are built-into buses already. |
| 01:53.49 | DocScrutinizer05 | what do I do when the damn thing doesn't let me book out? |
| 01:53.58 | DocScrutinizer05 | drive on and enjoy the ride? |
| 01:54.14 | gurki | wow. a channel that wants to build a phone partly for security reasons that discusses whether we should ve such a thing as a traveller-tracking system |
| 01:54.18 | gurki | *scnr* |
| 01:54.21 | wpwrak | you can file a written complaint at the corresponding office, in triplicate ;-) |
| 01:54.31 | DocScrutinizer05 | or hit the idiot that kicked me out before I had a chance to push my NFC badge to the reader? |
| 01:55.03 | DocScrutinizer05 | gurki: a) that's totally on topic, and b) nobody is discussing that |
| 01:55.08 | wpwrak | gurki: well, that's where these critters are heading :) of course, they *could* discard all the data at exit. but hey, why would they ? ;-) |
| 01:55.56 | gurki | DocScrutinizer05: i thing the *scnr* is the most important point of what i said :-) |
| 01:56.00 | gurki | think* |
| 01:56.07 | DocScrutinizer05 | we're discussing which usecases exists and how they work or fail. We're not discussing if we(SIC!) should implement such a system |
| 01:57.30 | wpwrak | gurki: and it's not as if you didn't have a choice. if you don't like it, you're free to walk ;-) |
| 01:57.46 | gurki | wpwrak: THAT is actually sth im afraid of ^^ |
| 01:58.01 | DocScrutinizer05 | and NFC in Neo900 is 100% under your control to disable it completely |
| 01:58.43 | wpwrak | some principle as with "security" searches at airports: nobody forces you to submit to this, you can always decline and not proceed towards boarding what would have been your flight. they even inform you of these "rights" of yours ;-) |
| 01:59.23 | DocScrutinizer05 | note to self: have a crowbar switch between PbF1 and PbF2, control Vbatt |
| 01:59.51 | Oksana | 'Pay' maximum fare and find the closest transportation-authority office to complain to them. Mail the misbehaving card to them for replacement? |
| 02:00.42 | DocScrutinizer05 | baically I don't care. It's not my system and I for sure won't get such wireless ticket |
| 02:00.57 | wpwrak | connect to GND, as in figure 14a ? :) |
| 02:01.09 | DocScrutinizer05 | particularly since I use public tranport too infrequently |
| 02:01.17 | DocScrutinizer05 | wpwrak: exactly |
| 02:01.31 | DocScrutinizer05 | but with a pair of FETs |
| 02:01.45 | DocScrutinizer05 | depeltion type |
| 02:01.51 | DocScrutinizer05 | arrrgh |
| 02:01.57 | DocScrutinizer05 | depletion type |
| 02:02.17 | DocScrutinizer05 | IOW active-off, passive-on |
| 02:02.19 | wpwrak | why bother ? just disallow standalone operation. what's not supported cannot go wrong |
| 02:03.08 | DocScrutinizer05 | depends. When we can find a host-controlled equivalent mode, then sure, why not |
| 02:04.13 | DocScrutinizer05 | actually I think I've seen something to the meaning of "doesn't care where power comes from" |
| 02:04.42 | DocScrutinizer05 | so not implementing field-powered would be totally the right thing to do |
| 02:05.07 | DocScrutinizer05 | I can't see the need to operate this thing without (charged) battery |
| 02:05.23 | wpwrak | would make sense if it didn't care about the power source. after all, the antenna may just be insufficient for it |
| 02:06.44 | DocScrutinizer05 | should we power it in sync with modem,or spend a dedicated power switch for it? |
| 02:06.58 | DocScrutinizer05 | I guess the latter |
| 02:08.25 | wpwrak | would make sense to be able to operate it independently from modem |
| 02:10.58 | DocScrutinizer05 | we however need to make sure that SIM power from modem is bypassing PN544 when PN544 is supposed to be diabled and powered down but modem is active |
| 02:11.35 | DocScrutinizer05 | otherwise PN544 would draw it's power from SIM power supply originating in modem |
| 02:11.43 | wpwrak | if their data paths are separate anyway, why even be concerned with the modem ? |
| 02:11.49 | DocScrutinizer05 | or *could* at least |
| 02:12.14 | wpwrak | allow modem and NFC independently to power SIM |
| 02:12.33 | DocScrutinizer05 | well, what else do you wanna do? add the both power pathes at SIM with two diodes? |
| 02:12.35 | wpwrak | not sure if we're allowed to add a power switch on the SIM side, too |
| 02:13.21 | wpwrak | the enable signals could be prioritized if this is a problem |
| 02:13.50 | DocScrutinizer05 | we're not talking about enable signals, we are dealing with power rails here |
| 02:14.27 | wpwrak | yes, but it's the same principle |
| 02:14.37 | wpwrak | add a FET as "ideal diode" |
| 02:14.42 | DocScrutinizer05 | modem has a power supply regulator for SIM, and PN544 has another one |
| 02:15.25 | wpwrak | pFET, gate on the opposing rail. just like one can mix usb power and battery |
| 02:15.34 | wpwrak | works in ben and anelok ;-) |
| 02:17.11 | DocScrutinizer05 | case a) both modem and NFC disabled: SIM power irrelevant. b) Modem enabled, NFC off: power needs to go directly from modem to SIM to not power up NFC. c) NFC enabled, modem off: SIM power provided by NFC. And now: d) modem and SIM both enabled: I think we should use application note circuit in this case |
| 02:19.04 | wpwrak | which AN ? |
| 02:19.13 | DocScrutinizer05 | ?? |
| 02:19.23 | wpwrak | "application note circuit" |
| 02:19.52 | DocScrutinizer05 | the one that said that modem power runs to SIM via NFC chip |
| 02:21.36 | DocScrutinizer05 | we should use the most versatile design there, which allows us to disconnect SIM completely. Would benefit our monitoring/sandboxing as well |
| 02:21.51 | wpwrak | yes, where is that ? page 21 of pn532 and page 25 of pn544 have nothing like that. |
| 02:22.21 | DocScrutinizer05 | I'm pretty sure I seen this |
| 02:22.28 | DocScrutinizer05 | don't ask me where |
| 02:22.31 | wpwrak | are there regulatory restrictions on disconnecting SIM power ? you mentioned that there would be for other kinds of interference |
| 02:24.03 | DocScrutinizer05 | 9.3.1Supply of SIM with SWP interface |
| 02:24.05 | DocScrutinizer05 | According to ETSI SWP specification, NFC controller can be the source of SIM supply (VCC pin). PN544 will offer this possibility wherever the SIM power comes from (PMU, battery, field). |
| 02:24.59 | DocScrutinizer05 | Nik mentioned something like that, but then a mux for pseudo dual-SIM is absolutely OK |
| 02:25.31 | DocScrutinizer05 | anyway SIM interface is part of cert |
| 02:26.25 | DocScrutinizer05 | I don't think there are any general restrictions, just the circuit "shall not be evil" |
| 02:26.49 | wpwrak | (etsi swp spec) okay, doesn't seem to say anything about modems. good. would have been a bit odd if they'd depend on each other. |
| 02:27.11 | wpwrak | (shell not be evil) bwahaha (-:C |
| 02:28.06 | DocScrutinizer05 | I guess a sharing mux to use one SIM in two modems concurrently is not suitable to pass cert |
| 02:28.26 | DocScrutinizer05 | for example |
| 02:29.02 | wpwrak | hmm yes, that would be an interesting case. is the bus even capable of sharing ? |
| 02:29.20 | DocScrutinizer05 | nope |
| 02:29.42 | DocScrutinizer05 | but you know, dem Ingenoer is nix zu schwoer |
| 02:30.15 | DocScrutinizer05 | modem powers up sim only when it plans to use it right away |
| 02:30.17 | DocScrutinizer05 | usually |
| 02:30.51 | DocScrutinizer05 | at least that's what I expect it to do, mere guessing |
| 02:31.28 | DocScrutinizer05 | then otoh that's maybe nonsense, regarding PIN auth |
| 02:32.10 | DocScrutinizer05 | I know for sure that modem can stop clock for SIM when not active (and is supposed to do that) |
| 02:32.26 | wpwrak | (ingenioer) yeah, perhaps you could fake some sort of "busy" signal while the other modem is serving itself. and i wouldn't be surprised if the protocol modem <-> sim had a lot of recover modes/states, so the modem wouldn't treat a reset in the middle as "hard" error. |
| 02:32.32 | DocScrutinizer05 | so you *could* find a way to share a SIM |
| 02:33.08 | DocScrutinizer05 | :nod: |
| 02:34.10 | DocScrutinizer05 | anyway that's not even faintly what we want to do |
| 02:34.45 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 02:34.54 | Oksana | Not implementing field-powered NFC? Not helping. Sometimes, when N900 was on very-low battery, I was even thinking about possibility of charging N900 wirelessly from card readers. They do not supply enough power to trickle charge the N900 itself, I suppose, but still, having NFC self-powered from antenna would be helpful. Of course, it can be made a configurable option. Supplementing... |
| 02:34.55 | wpwrak | yeah, just curious where roughly the limits are |
| 02:34.56 | Oksana | ...field-power with battery-power may potentially improve NFC range-or-speed? |
| 02:35.17 | DocScrutinizer05 | another requirement seems to be: either CardDetect or forced power down on modem, so you cannot remove SIM (and use it in a second modem) while first modem doesn't even notice SIM is gone |
| 02:36.55 | wpwrak | i hope they properly authenticate the "card detect" signal ;-)) |
| 02:36.56 | DocScrutinizer05 | wpwrak: see? that's why I *always* then to implement features that are there, and rather have a way to disable them under user control |
| 02:37.17 | DocScrutinizer05 | s/then /tend / |
| 02:37.55 | wpwrak | DocScrutinizer05: i just gently steer people away from such ideas :) |
| 02:38.16 | DocScrutinizer05 | no, we won't adopt any such policy for Neo900 |
| 02:38.31 | DocScrutinizer05 | no "we don't need that" in Neo900 |
| 02:38.33 | wpwrak | oh we will. if nno |
| 02:38.41 | wpwrak | grr. if not explicitly, then implicitly |
| 02:39.36 | wpwrak | at some point we'll have a design where all the important things work but a gazillion of these fringe things either don't, are untested, or tested with inconclusive results |
| 02:39.57 | DocScrutinizer05 | thanks Oksana, you saved my mind from straying into land of "we don't need that" |
| 02:40.54 | wpwrak | then the question will be whether to make the 400+ who'd be happy with that wait a few more months or disappoint the 2-3 people who really want the fringe things |
| 02:41.01 | DocScrutinizer05 | I don't care about inconclusive results or even untested. We won't eliminate resp kick out a function just to make our life easier |
| 02:41.18 | wpwrak | so it'll happen. in one way or another. |
| 02:42.44 | DocScrutinizer05 | apologetism |
| 02:44.23 | DocScrutinizer05 | there's a filed power option, it's simple to implement. It's even quite simple to disable under user control. I won't drop it just to make you happy because you don't see the usecase that Oksana obviously sees |
| 02:45.36 | DocScrutinizer05 | "stereo-in? we don't need that" |
| 02:46.12 | DocScrutinizer05 | "but it only takes two 0402 rsistors and maybe two capacitors" - "no, we don't need it" |
| 02:47.13 | DocScrutinizer05 | since OM I am allergic against that "we don't need it2 argument |
| 02:48.29 | wpwrak | if you have "user control", then you don't need it. so you must be operating in a context where no "user control" exists. e.g., cpu down or crashed. and suddenly the complexity moves from a couple of fets to persistent state and such. plus, you create a possible vulnerability: trick cpu into enabling field-powered nfc, then crash cpu. now you can do whatever you want with nfc without the cpu interfering. |
| 02:48.37 | DocScrutinizer05 | worst case user takes a toothpick and removes the two capacitors for field-powered mode |
| 02:49.35 | DocScrutinizer05 | yeah, when you call such scenario a vulnerability then we better stop using CPU at all |
| 02:49.43 | DocScrutinizer05 | let's build an analog cellphone |
| 02:50.09 | wpwrak | the retrophone ;-) |
| 02:50.22 | DocScrutinizer05 | and regarding persistent state, we have several such cases already |
| 02:50.24 | wpwrak | "original 1980 size" ;-) |
| 02:51.00 | DocScrutinizer05 | you seem to suffer from a lack of true Neo900 spirit today |
| 02:52.54 | DocScrutinizer05 | NB the chip already offers such persistent configuration options aiui |
| 02:53.24 | DocScrutinizer05 | it's actually debatable if we need additional security measures |
| 02:54.10 | DocScrutinizer05 | brute force shorting NFC antenna seems the only thing we might want to do |
| 02:54.46 | DocScrutinizer05 | everything else is supposed to be controllable via the chip's host interface |
| 02:55.18 | DocScrutinizer05 | secure mode simply is "no NFC, sorry", and that's it |
| 02:56.03 | DocScrutinizer05 | and i'm not sure we need a 100% secure mode when battery is out (even a empty battery is sufficient power to keep secure mode active) |
| 02:57.22 | DocScrutinizer05 | but in the end it's an implementation choice if no battery means secure mode or secure mode but NFC enabled |
| 02:57.23 | wpwrak | there's a "power down" command. scarily, it includes disabling all the host interfaces as wakeup sources. |
| 02:58.43 | DocScrutinizer05 | I haven't looked into recovery from power down. Prolly via some reset or whatever |
| 02:59.20 | wpwrak | well, maybe the chip would not accept the command in this case. doesn't say much about valid parameters. and there's no specific error code for that. but "bad parameter" would cover it (and pretty much anything else :) |
| 02:59.40 | DocScrutinizer05 | hm? |
| 02:59.55 | DocScrutinizer05 | I'm talking about a nRESET pin |
| 03:00.25 | DocScrutinizer05 | err NRST |
| 03:00.34 | DocScrutinizer05 | ;-D |
| 03:01.07 | DocScrutinizer05 | was that too obvious? ;-) |
| 03:02.32 | DocScrutinizer05 | or did you lose me completely? |
| 03:03.05 | DocScrutinizer05 | actually I don't get the part about parameters and error codes |
| 03:03.09 | wpwrak | NRESET on PN544 (which has the data sheet that describes pins). dunno about PN532 (which has the manual that describes commands) |
| 03:03.47 | DocScrutinizer05 | http://wstaw.org/m/2014/09/18/plasma-desktopkY1987.png |
| 03:04.06 | DocScrutinizer05 | NRST |
| 03:04.50 | DocScrutinizer05 | is too lazy to check if there's a inconsistency between the diagram and the table of pins/signals |
| 03:06.37 | wpwrak | (error codes) when you send a command to the PN532, it can accept or reject it. and it returns a status code |
| 03:06.52 | DocScrutinizer05 | idly wonders if there's no eval board for PN544 at all |
| 03:06.55 | wpwrak | yeah, pin descriptions call it NRESET |
| 03:07.26 | DocScrutinizer05 | anyway, n8 |
| 03:10.53 | wpwrak | (pn544) a complete manual set would be a good start ;-) |
| 03:11.09 | wpwrak | according to http://www.cnx-software.com/tag/pn544/ this is the board you wan: http://ar.mouser.com/ProductDetail/NXP-Semiconductors/OM5596-N5441U0269/?qs=MWRe%252bjyhxRvF7fNdiM6qXg== |
| 03:11.23 | wpwrak | of course EOL, unavailable, etc. |
| 03:38.26 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 03:54.38 | Oksana | Anytime :) Just imagine the horror of being stranded on a train, unable to exit it, because the transport-authority UICC-card is inside the completely-discharged phone, and field power "is not enough" for NFC. Fortunately, there are outlets inside the train, but then, you need to have a phone charger in your backpack... DocScrutinizer05thanks Oksana, you saved my mind from straying into... |
| 03:54.39 | Oksana | ...land of "we don't need that" |
| 04:09.30 | Oksana | Simply put, if this Single Wire Protocol goes over a single thin long wire, then user may 'cut' the wire and direct it to C6 contact of 'second', 'glued-on', UICC card. But, the user would need to obtain such UICC card first. I have never heard of UICC card being used which would be not-cellular. Though... I could take an 'expired', 0-balance cellular UICC for this. But, who would agree to... |
| 04:09.32 | Oksana | ...put 'secure app' (be it bank or transport) onto this 'blank' UICC card? |
| 04:14.09 | Oksana | Usecase! NFC SIM card with embedded Mifare DESFire technology, DragonFly, is being launched for the first time in Asia with AIS, and will enable a mobile phone to be used as an e-purse to pay for public transportation and goods in Bangkok. Service users can also directly top-up credit on their SIM card and check both their balance and transaction history using their mobile phones. The... |
| 04:14.11 | Oksana | ...dragonFly also allows rich applications to be embarked on the SIM. |
| 04:14.26 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 04:32.03 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 04:33.06 | *** join/#neo900 roottoor_ (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 04:52.43 | DocScrutinizer05 | yeah, maybe the time of NFC is yet to come. See how long it took SMS to become the hype it is today. And SMS been *for free* in the beginning |
| 04:54.20 | DocScrutinizer05 | my passport has a RFID aka NFC tag embedded since... 2008 |
| 04:56.02 | Oksana | Hmm... NFC-enabled phone can attempt to speak with RFID tag. But, since the tag has its own processor, tag will only give responses - not cart-blanch to copy it into another smart card. |
| 04:56.31 | DocScrutinizer05 | hm? |
| 04:57.31 | DocScrutinizer05 | yes, basically my Jolla can read the tag in my passport |
| 04:58.10 | DocScrutinizer05 | chips like PN544 can act as reader as well as emulate a tag |
| 04:58.15 | DocScrutinizer05 | PICC |
| 05:00.25 | Oksana | In 2008 Jeroen van Beek demonstrated that optional security mechanisms can be disabled by removing their presence from the passport index file. This allows an attacker to remove â amongst others â anti-cloning mechanisms (Active Authentication)... And when Anti-Cloning is disabled... |
| 05:00.27 | Oksana | In 2006 Lukas Grunwald demonstrated that it is trivial to copy passport data from a passport chip into a standard ISO/IEC 14443 smartcard using a standard contactless card interface and a simple file transfer tool. |
| 05:00.47 | Oksana | https://en.wikipedia.org/wiki/Biometric_passport#Attacks |
| 05:50.07 | *** join/#neo900 raccoon_ (~user@h-5-150-255-99.na.cust.bahnhof.se) |
| 06:19.59 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 06:24.44 | Oksana | Goodbye. |
| 06:50.46 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
| 07:13.45 | *** join/#neo900 lexik (lexik@nat.brmlab.cz) |
| 07:36.33 | *** join/#neo900 Oksana (~chatzilla@129.94.239.199) |
| 07:59.07 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 08:00.06 | *** join/#neo900 dos1 (~dos1@unaffiliated/dos1) |
| 08:00.20 | *** mode/#neo900 [+v dos1] by ChanServ |
| 08:53.22 | *** join/#neo900 kolp (~quassel@55d44084.access.ecotel.net) |
| 09:02.32 | *** join/#neo900 paulk-collins (~paulk@gagarine.paulk.fr) |
| 09:10.48 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 09:14.25 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 10:24.10 | *** join/#neo900 jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 11:13.57 | *** join/#neo900 freemangordon_ (~ivo@195.128.224.198) |
| 11:16.09 | *** join/#neo900 freemangordon_ (~ivo@195.128.224.198) |
| 11:25.14 | *** join/#neo900 freemangordon_ (~ivo@195.128.224.198) |
| 11:30.01 | *** join/#neo900 freemangordon_ (~ivo@85-118-92-25.mtel.net) |
| 11:35.34 | *** join/#neo900 R0ll3 (~quassel@31-211-200-248.customers.ownit.se) |
| 11:43.06 | *** join/#neo900 drathir (~kamiljk8@s51.linuxpl.com) |
| 12:57.47 | *** join/#neo900 b1101 (~b@fsf/member/b1101) |
| 13:06.42 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
| 14:05.27 | *** join/#neo900 silviof (~silviof@unaffiliated/silviof) |
| 14:15.58 | *** join/#neo900 che1 (~che@83.240.177.174) |
| 14:47.30 | *** join/#neo900 freemangordon (~freemango@46.249.74.23) |
| 15:07.47 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
| 15:23.42 | *** join/#neo900 modem (~modem@fsf/member/modem) |
| 15:26.18 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 15:46.49 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 16:05.52 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 16:08.20 | DocScrutinizer05 | >> At the moment, BlackBerry mobile phones are the only devices known to support software card emulation. How- ever, recent patches [18, 19] to the CyanogenMod aftermar- ket firmware for Android devices will enable this type of card emulation on Android devices with NXPâs PN544 NFC controller.<< |
| 16:10.36 | DocScrutinizer05 | many thanks to Walter for his invaluable silent support, providing goodies like this one to us |
| 16:12.43 | DocScrutinizer05 | www.medien.ifi.lmu.de/iwssi2012/papers/iwssi-spmu2012-roland.pdfâ |
| 16:17.26 | DocScrutinizer05 | short summary: PM544 supports the (classical) Secure Element appraoch where the SIM acts as SE attached to the NFC transceiver via SingleWireProtocol, but PN544 also supports emulation of such SE in software by ApplicationProcessor |
| 16:22.42 | DocScrutinizer05 | obviously such emulation depends on knowledge of the (secret) data stored in the real HW SE, for emulating existing solutions. For simple access control system contactless smart cards usually the issuer is either the user himself, or his employer, so access to that data is somewhat granted and PN544 is technicall capable of emulating basically all of those cards. For payment and other high security use-cases deployed by banks or other |
| 16:22.44 | DocScrutinizer05 | huge companies, that data frequently is a well guarded secret and deployment to end user is in form of a SIM card or a self conprised contactless smartcard like Visa Electron(?). Emulation is considered impossible for practical reasons, since the provider will not disclose the data |
| 16:27.48 | *** join/#neo900 paulk-collins (~paulk@gagarine.paulk.fr) |
| 16:29.41 | DocScrutinizer05 | on security from user's POV: yes, of course NFC offers a multitude of attack vectors, but all those are under control of user and the APE OS, and thus are of same class as any other exploit to the APE OS aimed at e.g. spying on your email passwords, your ssh private key or whatever. As long as user doesn't allow vulnerabilities in her/his OS by e.g. installing malware/spyware, NFC doesn't introduce any increased security threats |
| 16:29.54 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
| 16:31.34 | DocScrutinizer05 | (the previous statement doesn't apply to NFC immanent vulnerabilities like eavesdropping on communication between NFC device and a POS NFC reader, which can't get handled by hardware and can only be avoided by not using/enabling NFC on Neo900, which our users are free to do any time) |
| 16:35.09 | DocScrutinizer05 | Neo900 will warrant that NFC is disabled when user wants it to be disabled. There will be no backdoor to enable and operate NFC without user's consent. This will get implemented on a hardware level that can get evaluated and certified |
| 16:56.24 | freemangordon | DocScrutinizer05: tell me you're considering NFC chip on Neo900 :) |
| 16:57.12 | DocScrutinizer05 | err, that's exactly what we were discussing for the last 2 or 3 days, and what all the above is about |
| 16:57.53 | mvaenskae | DocScrutinizer05: is there anything you aren't planning on having disabled via hardware? :) |
| 16:57.54 | DocScrutinizer05 | I actually even decided that we want PN544 |
| 16:58.12 | freemangordon | sorry, I was disconnected from irc (damn empathy) most of the time |
| 16:58.21 | DocScrutinizer05 | ooh, sorry |
| 16:59.54 | freemangordon | I think I told you I have lots of knowledge in the area of card payments (be it contact or contactless), so I think I will be able to help a bit with the SW side of things |
| 17:00.23 | DocScrutinizer05 | mvaenskae: nope. since Neo900 product requirement specs somewhat shifted towards secure platform and counter-NSA-et-al eavesdropping and spying, there won't be any system in Neo900 that could create a vulnerability/threat and isn't controlled by hardware to make sure we can block any such threat |
| 17:00.52 | DocScrutinizer05 | freemangordon: I hoped for this statement since 3 days already :-) |
| 17:00.55 | freemangordon | one of the things I've done if S3 acting like MiFare card :) |
| 17:00.59 | mvaenskae | does the same count for any sensor included (meaning gyro and such)? |
| 17:01.03 | freemangordon | s/if/is |
| 17:01.54 | DocScrutinizer05 | mvaenskae: of course: they don't introduce any possible securtity threat thus they are already implicitly handled by above policy |
| 17:02.39 | mvaenskae | DocScrutinizer05: https://www.schneier.com/blog/archives/2014/08/eavesdropping_u.html gyroscopes can be used as microphones :) |
| 17:02.57 | DocScrutinizer05 | so what? only under OS control |
| 17:03.08 | freemangordon | the problem with EMV etc kernels is that they require expensive certification process with EMVCo. |
| 17:03.20 | freemangordon | (in regard to NFC payment) |
| 17:03.39 | DocScrutinizer05 | OS is considered safe by definition, since otherwise the only phone we could build is made of two cans and a string |
| 17:04.51 | mvaenskae | DocScrutinizer05: ok that is a solid basis one needs :) |
| 17:05.50 | DocScrutinizer05 | freemangordon: EMV? |
| 17:06.46 | freemangordon | http://en.wikipedia.org/wiki/EMV |
| 17:07.14 | freemangordon | very similar to payment process when using contactless cards |
| 17:07.23 | DocScrutinizer05 | freemangordon: Neo900 doesn't support a TC-style "secure platform" that could get certified for e.g. security-relevant emulations |
| 17:07.50 | freemangordon | if I read the backscroll correctly, that chip can use SIM as a secure element |
| 17:07.57 | DocScrutinizer05 | yes |
| 17:08.08 | freemangordon | that should be enough |
| 17:08.09 | DocScrutinizer05 | no APE support needed |
| 17:08.50 | freemangordon | SIM exports API(applet) to be used by a payment application |
| 17:08.59 | DocScrutinizer05 | ouch |
| 17:09.08 | DocScrutinizer05 | that's STK/SAT, right? |
| 17:09.13 | freemangordon | no |
| 17:09.33 | freemangordon | it is a java applet emulating a card |
| 17:09.40 | DocScrutinizer05 | or are you talking about the protocol on SWP |
| 17:09.50 | freemangordon | it is loaded either by MNO or online |
| 17:10.00 | freemangordon | SWP defines the HW level |
| 17:10.02 | DocScrutinizer05 | online is no problem |
| 17:10.03 | freemangordon | but yes |
| 17:10.51 | freemangordon | payment application sends APDUs to the card (read directore, application selet, read data, external authenticatio, etc, etc) |
| 17:11.08 | DocScrutinizer05 | but as I understand it, the basic "payment" only involves NFC transceiver and SIM SE, no? |
| 17:11.20 | freemangordon | yes |
| 17:11.42 | freemangordon | it is the same in POS devices using ordinary chip cards |
| 17:11.47 | DocScrutinizer05 | IOW the phone emulates a contactless credit card |
| 17:11.53 | DocScrutinizer05 | :-) |
| 17:11.56 | freemangordon | exactly |
| 17:12.10 | freemangordon | but there is no security in so-called "terminal application" |
| 17:12.20 | freemangordon | terminal == phone in our case |
| 17:12.21 | DocScrutinizer05 | "emulates" as it actually works on a hw level, without APE |
| 17:12.54 | DocScrutinizer05 | actually even without battery |
| 17:12.55 | freemangordon | yes |
| 17:13.13 | freemangordon | everything is in the SIM card |
| 17:13.20 | DocScrutinizer05 | yep |
| 17:13.28 | freemangordon | which can be accesses either via NFC or via SWP |
| 17:13.51 | DocScrutinizer05 | the SIM card can get accessed via NFC? |
| 17:14.13 | DocScrutinizer05 | I guess you want to rephrase that ;-) |
| 17:14.33 | freemangordon | I'll try |
| 17:14.56 | DocScrutinizer05 | SWP is the trace between PN544 and SIM |
| 17:15.07 | freemangordon | ÑÐµÑ |
| 17:15.09 | freemangordon | yes |
| 17:15.14 | DocScrutinizer05 | PN544 does the NFC RF TX/RX |
| 17:15.20 | freemangordon | yes |
| 17:15.52 | DocScrutinizer05 | PN544 also is capable to power the SIM from "field" |
| 17:15.59 | DocScrutinizer05 | so no battery needed |
| 17:16.12 | DocScrutinizer05 | no APE needed, obviously, without battery |
| 17:16.16 | freemangordon | yep, this is one of the NFC requirements iirc |
| 17:16.43 | freemangordon | ok, lemme try to rephrase: |
| 17:16.56 | DocScrutinizer05 | we will provide a method in hw to reliably block this operation mode |
| 17:17.16 | DocScrutinizer05 | (as well as all others same time) |
| 17:17.40 | freemangordon | what is accessed via NFC is not the SIM card, but the banks card. there are different domains in the "SIM" card |
| 17:17.51 | DocScrutinizer05 | yes |
| 17:18.12 | DocScrutinizer05 | tell me, could a SIM hold multiple comcurrent "bank domains" |
| 17:18.29 | freemangordon | yes |
| 17:18.41 | DocScrutinizer05 | like, say, a batch of contactless smart cards |
| 17:18.53 | freemangordon | those are called "applications" |
| 17:18.58 | DocScrutinizer05 | :nod: |
| 17:19.01 | freemangordon | thouhg... |
| 17:19.03 | DocScrutinizer05 | thanks! :-) |
| 17:19.11 | freemangordon | wait |
| 17:19.23 | freemangordon | it is deffinitely true for contact cards |
| 17:19.46 | DocScrutinizer05 | then it MUST be true fro PICC |
| 17:19.59 | freemangordon | not so sure about contactless, as the whole process of payment takes < .5 sec |
| 17:20.04 | DocScrutinizer05 | aiui the NFC is just another PHY, no? |
| 17:20.15 | freemangordon | yes |
| 17:20.45 | freemangordon | but I am not sure one can have "application selection" when using the contactless part |
| 17:20.51 | freemangordon | need to check that |
| 17:21.14 | freemangordon | (it was moe than 6 months ago I did my last contactless card certification :) ) |
| 17:21.18 | DocScrutinizer05 | I think when we implement a PN544 with SWP to our beloved Neo900, we're on safe side of fence anyway |
| 17:21.24 | freemangordon | yes |
| 17:22.02 | freemangordon | re hw blocking - I hope this will be user controlable, even with flat battery |
| 17:22.41 | freemangordon | the idea behind this is - you must be able to use your money even if your battery is flat |
| 17:23.20 | DocScrutinizer05 | I'm undecided about battery. I tend to assume we guarantee it to work with battery flat to point of hard system shutdown, but maybe we don't warrant a consistent state when battery removed |
| 17:24.05 | DocScrutinizer05 | I further tend to allow NFC when battery removed |
| 17:24.46 | DocScrutinizer05 | if you want to forbid NFC as well, simply don't close battery lid after removing battery (lid holds antenna) |
| 17:25.20 | freemangordon | hmm, might work, though not much user friendly |
| 17:26.05 | DocScrutinizer05 | err? more user friendlyness for nich case of using NFC with battery removed? Aren't you asking for a bit too much ;-) |
| 17:26.22 | freemangordon | no, no |
| 17:26.25 | freemangordon | I meant: |
| 17:26.45 | freemangordon | if the battery is in, but flat, so you can't boot the OS to enable NFC |
| 17:27.05 | freemangordon | then you must remove the battery in order to use it |
| 17:27.09 | freemangordon | (NFC) |
| 17:27.14 | DocScrutinizer05 | look, with absolutely flat (or no) battery user has no means whatsoever to toggle the persistent state of enable-NFC-flag anyway |
| 17:27.57 | DocScrutinizer05 | we warrant persistent state of such flag even for completely flat battery |
| 17:28.09 | freemangordon | exactly. that is why you should enable NFC when the battery is out |
| 17:28.20 | freemangordon | no matter what the flag is |
| 17:28.23 | DocScrutinizer05 | (unless deep discharge protection in batt kicked in) |
| 17:28.46 | DocScrutinizer05 | (enable when batt out) which is exactly what I said above |
| 17:28.53 | freemangordon | as a backup when you need your money, but you don;t have access to charger |
| 17:28.54 | DocScrutinizer05 | :-) |
| 17:28.57 | freemangordon | yep |
| 17:29.08 | *** join/#neo900 che1 (~che@83.240.177.174) |
| 17:29.09 | freemangordon | "hmm, might work, though not much user friendly" |
| 17:29.15 | freemangordon | :) |
| 17:29.31 | freemangordon | anyway |
| 17:29.39 | DocScrutinizer05 | I don't see how to make that any more user friendly |
| 17:29.42 | freemangordon | I am more than glad there will be NFC in Neo900 |
| 17:29.47 | freemangordon | you can;t |
| 17:30.21 | freemangordon | unless you put a HW switch to enable/disable NFC. Not that I recommend such a solution |
| 17:30.32 | DocScrutinizer05 | when user disabled NFC and then runs flat on battery, there's no means other than mechanical hardware to toggle that flag |
| 17:30.43 | freemangordon | :nod: |
| 17:30.45 | DocScrutinizer05 | hehe, exactly |
| 17:31.54 | freemangordon | you should laser-draw "remove me and the battery to enable NFC" on the backcover :P |
| 17:32.20 | DocScrutinizer05 | so we will have NFC enabled unconditionally in the special case of "battery removed", and device comes with a warning explaining that and pointing out that you can disable NFC by not closing the battery lid |
| 17:32.33 | freemangordon | yep |
| 17:32.36 | freemangordon | sounds sane |
| 17:33.21 | DocScrutinizer05 | thanks! :-) |
| 17:35.04 | DocScrutinizer05 | do you happen to have access to decent datasheets/TRM for PN544? |
| 17:35.28 | freemangordon | no, I work on a bit higher level |
| 17:35.54 | freemangordon | kernel, payment application, host system |
| 17:36.04 | freemangordon | but not on L1 stuff |
| 17:36.30 | freemangordon | is that chip even available? |
| 17:36.32 | DocScrutinizer05 | of course. Just asking. Thought as much |
| 17:36.47 | DocScrutinizer05 | seems so. Lemme check |
| 17:37.47 | freemangordon | oh, it even supports MiFare |
| 17:37.58 | freemangordon | I guess this is the same chip in S3 |
| 17:38.26 | DocScrutinizer05 | yes, I think so |
| 17:38.29 | freemangordon | MOQ=490 |
| 17:38.34 | freemangordon | not bad |
| 17:38.38 | DocScrutinizer05 | where? |
| 17:38.49 | DocScrutinizer05 | DK had no hits even |
| 17:38.50 | freemangordon | http://www.nxp.com/documents/leaflet/75016890.pdf |
| 17:39.20 | DocScrutinizer05 | hmm, so NXP ships them? great! |
| 17:39.31 | freemangordon | looks like |
| 17:40.54 | freemangordon | pricong varies between 2 and 8 $ |
| 17:40.55 | DocScrutinizer05 | http://www.findchips.com/search/pn544 |
| 17:40.59 | freemangordon | *pricing |
| 17:41.39 | freemangordon | phew, seems like it can be easily found |
| 17:41.41 | DocScrutinizer05 | mouser too |
| 17:42.31 | freemangordon | hehe "Crystals 27.12MHz HCR OPTMZD NXP PN544" |
| 17:42.32 | DocScrutinizer05 | I guess it shouldn't be a risk part |
| 17:42.37 | freemangordon | looks like |
| 17:43.01 | DocScrutinizer05 | freemangordon: we have problems with the antenna though |
| 17:43.10 | DocScrutinizer05 | placing it |
| 17:43.25 | DocScrutinizer05 | RF design of N900 isn't made with NFC in mind |
| 17:44.06 | DocScrutinizer05 | the obvious solution to place antenna into battery lid may or may not work |
| 17:45.27 | DocScrutinizer05 | if we could source a evaluation board for PN544 8or any other NFC eval board) we could test an antenna glued to batt lid in a N900 |
| 17:46.46 | freemangordon | NXP offers evaluation board iiuc |
| 17:46.55 | DocScrutinizer05 | mhm |
| 17:46.58 | DocScrutinizer05 | fine |
| 17:47.03 | DocScrutinizer05 | we might need to get one |
| 17:47.46 | DocScrutinizer05 | I'm not only concerned about efficacy (or woring at all) of NFC antenna, I'm also wondering if it might detune the other antennas |
| 17:48.03 | freemangordon | see "Design-In Kit" on http://www.nxp.com/documents/leaflet/75016890.pdf |
| 17:48.12 | DocScrutinizer05 | s/wori/worki/ |
| 17:48.17 | freemangordon | yeah |
| 17:49.42 | DocScrutinizer05 | I already wondered if we might integrate the NFC antenna coil along perimeter of the PCB |
| 17:50.09 | DocScrutinizer05 | which at least shouldn't detune any other antenna |
| 17:50.13 | freemangordon | ever seen contactless card coil? |
| 17:50.34 | DocScrutinizer05 | err, some, though not exactly for 14MHz NFC |
| 17:51.05 | DocScrutinizer05 | usually some windings of a coil with a rather large open area |
| 17:51.29 | freemangordon | some? |
| 17:51.32 | freemangordon | http://dgzg618.en.alibaba.com/product/1615930339-220854488/RFID_Contactless_IC_Card_Air_Coil.html |
| 17:51.47 | DocScrutinizer05 | yup |
| 17:51.55 | DocScrutinizer05 | also come as flex PCB |
| 17:52.39 | DocScrutinizer05 | I'm pondering the small diameter long ones |
| 17:53.31 | DocScrutinizer05 | anyway the antena needs further R&D |
| 17:53.39 | DocScrutinizer05 | and evaluation |
| 17:55.56 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 17:59.48 | mvaenskae | DocScrutinizer05: if one wanted to secure some case parts themselves for the neo900, would you recommend it or how are you going to implement such changes like an nfc antenna? |
| 18:02.20 | DocScrutinizer05 | we generally implement all "changes" in a way so we can provide "conversion kits" to customers only getting a NeoN board to use with their N900 case_et_al |
| 18:02.41 | DocScrutinizer05 | NFC antenna however is unclear yet. |
| 18:02.50 | freemangordon | DocScrutinizer05: a bit of OT, but any clue? : |
| 18:02.54 | freemangordon | "hald-addon-bme: bme_bytes_read: [fd=10] poll TIMEOUT " |
| 18:02.56 | freemangordon | and so on |
| 18:03.24 | freemangordon | ended with " BME: crash detected -> rebooting" |
| 18:03.24 | DocScrutinizer05 | ummm |
| 18:03.51 | DocScrutinizer05 | bme no access to bq24150? thanks to kernel/module occupying I2C? |
| 18:04.07 | freemangordon | you're a smart guy :) |
| 18:04.08 | DocScrutinizer05 | check fd10 |
| 18:04.23 | freemangordon | Sep 18 20:46:26 Nokia-N900 kernel: [36235.404663] lirc_dev: IR Remote Control driver registered, major 246 |
| 18:05.21 | freemangordon | this is my GF's device, someone installed QtIrreco on it |
| 18:05.29 | mvaenskae | DocScrutinizer05: alright, btw, are you thinking about sourcing used n900 devices for parts? |
| 18:05.31 | DocScrutinizer05 | <PROTECTED> |
| 18:05.40 | freemangordon | and somehow it got started (qtirreco) |
| 18:05.47 | freemangordon | naah, it already rebooted |
| 18:05.51 | DocScrutinizer05 | mvaenskae: doesn't fly, nobody offering them in volumes |
| 18:05.56 | freemangordon | I am reading syslog |
| 18:07.00 | mvaenskae | ebay might have every now and them some used n900 devices which are broken in some way or another but has most of the parts needed for just a pcb change |
| 18:08.47 | DocScrutinizer05 | yes, that's afeasible path for users, not for manufacturer. I strongly recommend to every user to get such used (broken) N900 and only buy the NeoN board. We're not happy with the sourcing situation for N900 mech parts |
| 18:10.14 | mvaenskae | i will then try getting a device for cheap, i am not sure if my cover really holds up well as i am missing a screw or two i believe and broke my keyboard frame thingy a bit :/ |
| 18:10.40 | jake42 | got himself a n900 with missing usb connector in acceptable condition for ~25⬠|
| 18:11.04 | DocScrutinizer05 | it's impossible we get a 500some used N900 and check each and everyone of them for scratches and defect pixels and whatnot, disassemble them and use them for Neo900. And we don't have all spare parts secured yet |
| 18:11.25 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 18:12.50 | mvaenskae | understandable |
| 18:12.55 | DocScrutinizer05 | so getting your very own N900 for revamp/light-swap is definitely a good thing and much appreciated and recommended by Neo900 group |
| 18:13.12 | mvaenskae | jake42: nice steal, was if off of ebay? |
| 18:15.11 | jake42 | mvaenskae: yep, though it just said it is sold as defect as not able to test |
| 18:16.06 | *** join/#neo900 Kabouik (~quassel@118.215.136.88.rev.sfr.net) |
| 18:16.15 | mvaenskae | hm, ebay is a bit difficult for me sadly, i will never use paypal :) |
| 18:16.26 | jake42 | (paypal) me neither |
| 18:16.58 | mvaenskae | ebay doesn't require paypal anymore? |
| 18:17.13 | jake42 | don't recall every having problems paying via money transfere |
| 18:17.56 | DocScrutinizer05 | ebay offers a changing set of payment options on every single offer |
| 18:18.05 | jake42 | could be the the seller is forced to accept payment from paypal, but as a customer you dont have to use paypal |
| 18:18.12 | wpwrak | hmm... case parts: http://articulo.mercadolibre.com.ar/MLA-522799636-carcasa-nokia-n900-ctecladotapa-de-bateria-_JM |
| 18:18.18 | mvaenskae | oh, cool, gotta ask my mum if she still has her ebay account around and can have it sent to a friend of hers and then to me :) (will be cheaper that way, switzerland is not EU) |
| 18:18.26 | wpwrak | that's about USD 22-23 |
| 18:18.47 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 18:18.53 | DocScrutinizer05 | wait WUT??? US Dollar 190.- ??? |
| 18:19.09 | DocScrutinizer05 | ooh |
| 18:19.10 | mvaenskae | DocScrutinizer05: amazon has a fully working 280eur n900 |
| 18:19.46 | DocScrutinizer05 | mvaenskae: great, but a) too expensibve for Neo900 UG and b) most certainly not in volumes |
| 18:19.46 | mvaenskae | pardon, 400 eur |
| 18:19.53 | DocScrutinizer05 | haha |
| 18:19.55 | mvaenskae | that is prettz insane |
| 18:20.32 | DocScrutinizer05 | might turn out to be a stale 5 year old offer |
| 18:20.35 | mvaenskae | jake42: thanks for clarifying the ebay situation :) |
| 18:21.03 | jake42 | mvaenskae: it's just IIRC ;-) |
| 18:21.55 | jake42 | well the customer part, not, I know that one for sure |
| 18:22.39 | wpwrak | freemangordon: good to have an NFC expert at hand :-) i have a couple of questions, too |
| 18:22.46 | mvaenskae | wow, a working n900 that looks in very mint condition from the outside and 3 days left; better try getting it for cheap :) |
| 18:22.51 | DocScrutinizer05 | wpwrak: the shell case is the smallest problem, though even those often come without magnet in kickstand. But the other parts are more of a problem, cases are available in abundance, in all colors |
| 18:23.12 | freemangordon | wpwrak: not exactly NFC expert, rather card payments expert ;) |
| 18:23.30 | freemangordon | NFC is just a "wire" |
| 18:23.40 | DocScrutinizer05 | :-D |
| 18:23.53 | wpwrak | 1) the PN544 does't have great documentation and seems to be oldish (e.g., the eval board seems to be well EOL). you wouldn't happen to know a more modern chip ? |
| 18:24.12 | jake42 | mvaenskae: if it is advertised as still working, it will cost somewhere between 50-80⬠|
| 18:24.21 | freemangordon | no, as I said I am more on the higher level stuff, not L1 |
| 18:24.45 | freemangordon | wpwrak: BTW there is newer chip, in S3, but afaik it is unobtanium |
| 18:24.55 | DocScrutinizer05 | wpwrak: however if you can get one of those (when they are not as expensive as 190 USD) it would help to evaluate what's available, regarding build qualtity etc |
| 18:24.56 | wpwrak | 2) how does one put new applications into the SIM ? is there a standard mechanism where one just drops some package into the SIM or does this require special applications ? |
| 18:25.32 | freemangordon | hmm, it is the same according to google |
| 18:26.44 | wpwrak | 3) and, higher-level stuff now, from a customer's perspective, how many of the "NFC" applications they see will be of the card emulation type and how many will require some closed application ? |
| 18:27.05 | DocScrutinizer05 | I don't consider PN544 "oldish". It's source-able, it has all features we need, and it has linux support |
| 18:27.24 | freemangordon | https://d3nevzfk7ii3be.cloudfront.net/igi/iSxZ1SQMJAKAnXZo.huge |
| 18:27.30 | freemangordon | the "green" one |
| 18:27.33 | DocScrutinizer05 | it still seems state-of-the-art |
| 18:27.46 | mvaenskae | jake42: well, it has all accessory included and the keyboard is spotless compared to mine; putting in 50 eur to get a "brand-new" neo900 is worth it i feel :) |
| 18:27.48 | wpwrak | DocScrutinizer05: what worries me is that there's extremely little information about it on NXP's site |
| 18:28.12 | DocScrutinizer05 | yes |
| 18:28.15 | freemangordon | wpwrak: ttp://www.nxp.com/documents/leaflet/75016890.pdf |
| 18:28.18 | wpwrak | and the EVB they made for it seems to be generally unavailable |
| 18:28.29 | freemangordon | they say they provide docs and source code with the eval board |
| 18:28.34 | mvaenskae | also the fresher it looks the longer the neo900 will likely hold :) |
| 18:29.15 | jake42 | and the more expensive it will be :-) |
| 18:29.20 | DocScrutinizer05 | ((provide docs and source code with the eval board)) I think the code is in main linux already. The docs should be available *somewhere* |
| 18:29.30 | mvaenskae | jake42: it is a one of the kind chance ;) |
| 18:29.42 | mvaenskae | there is but one neo900 i will own :) |
| 18:30.36 | freemangordon | wpwrak: on 2) - as I said I need to check, but my vague memories tell me you can't select application via teh contactless interface, there is one "default" one |
| 18:30.40 | wpwrak | (docs *somewhere*) yes. what bothers me that the usual search doesn't seem to find much. even your document, while more extensive than anything NXP show publicly, is rather castrated |
| 18:31.02 | freemangordon | applications are loaded via loading a java applet in to te SIM card |
| 18:31.38 | freemangordon | if it si a java card |
| 18:31.50 | wpwrak | the the mechanism for loading that java applet is "open" ? |
| 18:32.07 | freemangordon | yep, but you need to authorise with the issuer keys ;) |
| 18:32.15 | *** join/#neo900 che1 (~che@83.240.177.174) |
| 18:32.19 | DocScrutinizer05 | it's called SIM ToolKit aiui |
| 18:32.20 | freemangordon | before you are given the rights to do it |
| 18:32.42 | wpwrak | issuer ... of the SIM card ? |
| 18:32.50 | freemangordon | hmm, no, at least when you load the applet via SWP |
| 18:33.14 | DocScrutinizer05 | ooh, that's interesting. didn't know you can load via SWP |
| 18:34.04 | freemangordon | wpwrak: there are a couple of security domains in the SIM, the "master" key is owned by the MNO, but it provides the bank as master key for the bank's SD. this is simplified, but still the truth |
| 18:34.23 | freemangordon | DocScrutinizer05: that is the way to load the applet "online" |
| 18:34.27 | DocScrutinizer05 | so the idea is that at your bank POS termminal they install their own cert to the SIM via NFC, by authenticating with the key they got from SIM provider? |
| 18:34.39 | freemangordon | by opening a website, for example |
| 18:34.59 | freemangordon | no, certificates and DES keys are preloaded |
| 18:35.01 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 18:35.24 | DocScrutinizer05 | well, s/cert/application/ |
| 18:35.54 | DocScrutinizer05 | how would a website/browser access SWP? |
| 18:36.15 | freemangordon | iirc you can't load an application via NFC |
| 18:36.16 | DocScrutinizer05 | via NP544 host interface? |
| 18:36.20 | freemangordon | yes |
| 18:36.35 | DocScrutinizer05 | aah, ok |
| 18:36.41 | freemangordon | by sending APDUs to the card |
| 18:36.56 | wpwrak | (preloaded) so they can't authorize new companies without replacing the SIM ? |
| 18:37.03 | freemangordon | SWP appears as USB port on S3 IIRC |
| 18:37.20 | freemangordon | wpwrak: company? we are talking banks here ;) |
| 18:37.38 | mvaenskae | pardon, DES?! |
| 18:37.39 | freemangordon | at least here only banks are allowed to issue cards |
| 18:37.46 | freemangordon | well, 3DES |
| 18:38.02 | mvaenskae | still doesn't make it better |
| 18:38.15 | DocScrutinizer05 | so path-3 in http://www.medien.ifi.lmu.de/iwssi2012/papers/iwssi-spmu2012-roland.pdf |
| 18:38.21 | DocScrutinizer05 | page2 |
| 18:38.23 | freemangordon | it makes it, as you do CBC MAC with IV |
| 18:39.08 | mvaenskae | i thought triple des was useless these days |
| 18:39.20 | wpwrak | freemangordon: hmm, i guess shops may have fidelity / discount cards and such |
| 18:39.44 | freemangordon | your PIN gets 3DES encrypted when send onine, if you are lucky to live in Europe |
| 18:40.02 | DocScrutinizer05 | we need to set up a glossary of terms and what they mean. |
| 18:40.04 | freemangordon | not sure if 3DES is a must in USA |
| 18:40.17 | freemangordon | 3DES is tripple-des |
| 18:40.30 | DocScrutinizer05 | banks are not issuing any "cards" we may use in Neo900 |
| 18:40.42 | freemangordon | wrong |
| 18:41.10 | DocScrutinizer05 | maybe they cooperate with GSM carriers |
| 18:41.55 | freemangordon | exactly |
| 18:42.04 | DocScrutinizer05 | to offer some O2 or verizon or T-Mobile card with added value which is the bank's wallet application |
| 18:42.12 | freemangordon | :nod: |
| 18:42.30 | freemangordon | usually NFC is used as a wallet |
| 18:42.44 | DocScrutinizer05 | The question been if you can get that application installed on the SIM you already own |
| 18:43.07 | DocScrutinizer05 | at the bank's POS |
| 18:43.25 | freemangordon | no, you can't do thing like that on a POS device afaik |
| 18:43.29 | DocScrutinizer05 | por even by the bank sending you an email with the needed data chunk as attachment |
| 18:43.36 | freemangordon | you can only make authorisations |
| 18:43.50 | freemangordon | MNO can load it via SMS ;) |
| 18:44.03 | freemangordon | and this is not STK |
| 18:44.04 | DocScrutinizer05 | what's MNO? |
| 18:44.22 | freemangordon | Mobile Network Provider |
| 18:44.28 | freemangordon | oops |
| 18:44.55 | freemangordon | "Operator" |
| 18:45.12 | DocScrutinizer05 | so the banks sends you an SMs that installs the application to your SIM, whatever that SIM might be? |
| 18:47.16 | freemangordon | no, MNO sends a series of SMSes |
| 18:47.18 | DocScrutinizer05 | theoretically this might work that way |
| 18:47.51 | DocScrutinizer05 | whoever sends it technically. I think the bank sends it via a special API they got to MNO |
| 18:48.29 | freemangordon | yep, when there is such a cooperation, MNO and banks have channel to transfer data |
| 18:48.42 | DocScrutinizer05 | which allows them to send SMS with a few flags set that "normal users" cannot have set |
| 18:48.54 | freemangordon | yep |
| 18:49.07 | freemangordon | it is a special type of SMS |
| 18:49.12 | DocScrutinizer05 | yep |
| 18:49.16 | DocScrutinizer05 | I know |
| 18:49.23 | freemangordon | I am not even sure the user gets notified at all |
| 18:49.34 | DocScrutinizer05 | that's depending on modem afaik |
| 18:49.54 | freemangordon | don;t think so, it is like if your SIM keys got replaced |
| 18:50.03 | freemangordon | by the operator |
| 18:50.05 | DocScrutinizer05 | some modems even allow configuring if you see notification and are allowed to accept/reject or not |
| 18:50.34 | freemangordon | could be, won't argue on that one |
| 18:50.50 | DocScrutinizer05 | I'm not exactly sure on it either |
| 18:51.14 | *** join/#neo900 che1 (~che@g140.tum.vpn.lrz.de) |
| 18:51.36 | DocScrutinizer05 | P*S8 AT command reference manual should have any info available on that that's relevant for us |
| 18:52.23 | freemangordon | see https://code.google.com/p/seek-for-android/wiki/SCAPI_modules_png |
| 19:01.36 | DocScrutinizer05 | yeah, indeed SD cards also can act as SE |
| 19:02.30 | freemangordon | re AT commands - see https://code.google.com/p/seek-for-android/wiki/UICCSupport |
| 19:03.32 | freemangordon | if it is not supported by the modem, we should implement that in the modem driver. not matter if it is USB iface |
| 19:03.55 | freemangordon | if we want to stai compliant ofc |
| 19:03.58 | freemangordon | *stay |
| 19:04.48 | DocScrutinizer05 | when those commands were not supported by modem, then no way to implement them in driver |
| 19:05.44 | freemangordon | sure there is, by splitting the channels in 2 - one for the baseband and one for pn544 driver |
| 19:05.53 | freemangordon | *the channel |
| 19:06.23 | freemangordon | so modem commands go to the modem and uicc - to pn544 |
| 19:06.36 | DocScrutinizer05 | oooh |
| 19:06.42 | DocScrutinizer05 | I see |
| 19:07.06 | DocScrutinizer05 | I don't think such driver will make it upstream ;-) |
| 19:07.12 | freemangordon | or something like that |
| 19:07.52 | freemangordon | I am almost sure USB driver allows filter drivers |
| 19:08.13 | freemangordon | or serial or... dunno |
| 19:08.20 | freemangordon | :) |
| 19:08.32 | freemangordon | but that can be upstreamed (filer drivers) |
| 19:08.39 | freemangordon | IMO |
| 19:09.03 | DocScrutinizer05 | hatever, it seems to be already implemented and working in android. |
| 19:09.47 | DocScrutinizer05 | and it doesn't really answer the question if modem<->SIM SMS activity can get intercepted/notified by modem or not |
| 19:10.13 | freemangordon | sure, it is another beer |
| 19:11.17 | DocScrutinizer05 | It actually also doesn't say anything about SWP protocil supporting this communication |
| 19:12.32 | DocScrutinizer05 | when NFC OTA can't download new applications to the SIM via SWP, so why should APE be able to do so, using same SWP via NP544 host interface |
| 19:13.33 | DocScrutinizer05 | NP544 *might* handle the two communication pathes differently, but there's nothing that suggests this |
| 19:13.38 | freemangordon | operator can download anything in the SIM. amd it is not using SWP |
| 19:13.44 | freemangordon | but the normal SIM iface |
| 19:15.22 | DocScrutinizer05 | I'm afk, need dinner |
| 19:20.08 | DocScrutinizer05 | modem supports CSIM but not CCHO et al |
| 19:21.53 | freemangordon | that might suffice |
| 19:24.33 | DocScrutinizer05 | yeah, CSIM is pretty universal, but it has restrictions on what you're allowed to do with/by it |
| 19:25.49 | DocScrutinizer05 | http://wstaw.org/m/2014/09/18/plasma-desktopiS1987.png |
| 19:26.12 | *** join/#neo900 Liknus10 (~Liknus10@host254-183-dynamic.54-79-r.retail.telecomitalia.it) |
| 19:26.27 | Liknus10 | Hi all! ;) |
| 19:27.23 | DocScrutinizer05 | hi, and bbl/afk |
| 19:27.23 | freemangordon | DocScrutinizer05: as long as MNO can load applet in the card, I am not concerned about whether modem supports USIM commands or not |
| 19:27.29 | freemangordon | NFC will work |
| 19:33.31 | DocScrutinizer05 | http://people.openmoko.org/joerg/calypso_moko_FW/all_version__CHANGELOG.txt >> === Moko9-Beta2 === * Adds "AT+CSIM" (for swisscom)<< |
| 19:36.04 | DocScrutinizer05 | RMS will *love* that ;-) |
| 19:36.31 | DocScrutinizer05 | is it software? can user update it? |
| 19:36.47 | DocScrutinizer05 | is it part of the device? |
| 19:51.49 | *** join/#neo900 roottoor (~100010010@c-76-21-83-47.hsd1.ca.comcast.net) |
| 19:57.18 | wpwrak | hmm yes, he may have to burn his SIMs when he realizes what's going on :) |
| 20:38.12 | DocScrutinizer51 | on topic: badUSB |
| 20:38.51 | DocScrutinizer51 | Karsten Nohl |
| 20:42.04 | DocScrutinizer51 | https://srlabs.de/badusb-at-black-hat/ |
| 21:28.39 | *** join/#neo900 menesas (~newsbeute@ctv-95-173-44-211.vinita.lt) |
| 22:04.15 | drathir | DocScrutinizer51: can i pm You? |
| 22:04.26 | DocScrutinizer05 | sure, go ahead |
| 22:04.47 | DocScrutinizer05 | though I'm only available for another max 5 min |
| 22:05.44 | DocScrutinizer05 | ooh, please don't PM *51 |
| 22:06.04 | DocScrutinizer05 | it's my mobile alrer ego |
| 22:06.33 | drathir | DocScrutinizer05: oh that You clonned sorry ;/ |
| 22:06.52 | mvaenskae | DocScrutinizer05: why not tmux + irssi + ssh for just pne account? :) |
| 22:07.14 | DocScrutinizer05 | I prefer xchat |
| 22:07.37 | mvaenskae | alright, not going to make you feel guilty for it :) |
| 22:07.44 | DocScrutinizer05 | and I have a separate client not running via ZNC bouncer on purpose |
| 22:07.47 | mvaenskae | everyone has their preferences :) |
| 22:07.53 | drathir | still server seddion needed for tmux+irssi... |
| 22:08.02 | drathir | session* |
| 22:08.42 | DocScrutinizer05 | when ZNC (or complete server) gies down, DocScrutinizer05 may still be alive. And vice versa |
| 22:08.50 | DocScrutinizer05 | goes* |
| 22:08.52 | mvaenskae | what is a bouncer btw? |
| 22:09.03 | DocScrutinizer05 | ~wiki ZNC |
| 22:10.28 | mvaenskae | thanks for the link :) i am sometimes too dumb to google stuff :( |
| 22:14.24 | DocScrutinizer05 | also ZNC hides the reconnects of xchat during roaming from the channel |
| 22:14.38 | DocScrutinizer05 | at least I hope it still does ;-) |
| 22:15.04 | DocScrutinizer05 | how often do you see DocScrutinizer51 leaving and rejoning the channel? |
| 22:15.39 | DocScrutinizer05 | drathir: also ask in #maemo-ssu |
| 22:15.58 | DocScrutinizer05 | somebody there must know the answer, it has been done before |
| 22:45.14 | Oksana | What does certification process with EMVCo give? Besides 'beautiful' addition of Neo900 to paper-list of Visa certified devices? Is it possible to use NFC-SWP-device and NFC-app-on-SIM for payments without Visa certifying the device beforehand? |
| 22:45.16 | Oksana | Can NFC antenna be used to recharge the phone battery? Like microUSB port: data mode, or charging mode. "Flexible power supply" is vague. DocScrutinizer05the obvious solution to place antenna into battery lid may or may not work |
| 22:47.46 | ds2 | recharge with a proprietary standard, maybe |
| 22:47.55 | ds2 | but NFC antennas aren't very good power xfers, AFAIK |
| 22:49.21 | Oksana | Hmm... So Qi wireless charging and NFC would have to somehow complement each other... Because there is hardly ever a usecase for Qi and NFC working at the same time... Unless you are recharging from Qi, and peer-to-peer NFC-speaking at the same time... So... If I have a Mifare S70 card in my hands... Would PN544 chip be enough to emulate it? |
| 22:51.51 | *** join/#neo900 ds2 (noinf@rehut.com) |
| 22:52.19 | ds2 | they operate on different frequencies |
| 22:57.20 | Oksana | And that's the problem. Operating at different frequencies is helpful when you want to use both of them at the same time. Which is rarely seen. Maybe, because most phones do not have both Qi and NFC. Hmm... Let me see, Qi charging and NFC downloading music-or-video to phone at the same time? Or NFC uploading photographs from phone to computer at the same time as phone is charging from Qi?.. |
| 22:59.22 | Oksana | I just cannot put it into my head that it is possible to have two active coils in one phone at the same time. And do not forget all the other antennae! And integrating NFC coil into Estel's aluminium back-cover is additional complication... |
| 23:01.16 | DocScrutinizer05 | LOL, forget about that |
| 23:01.48 | DocScrutinizer05 | alu back cover isn't compatible with *any* of the RF design of N(eo)900 |
| 23:01.58 | *** join/#neo900 jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 23:02.02 | DocScrutinizer05 | even Estel admits that |
| 23:02.55 | ds2 | there are too many radios on the N900 to screw with the RF stuff in any way |
| 23:20.48 | wpwrak | (charging over NFC) hey, why not :) if you feed it that way for a few year or so, you may be able to deliver as much energy as one would need to actually charge a battery ;-) |
| 23:21.31 | wpwrak | btw, one argument against field-powered operation: http://www.wisdom.weizmann.ac.il/~yossio/rfid/ |
| 23:22.09 | DocScrutinizer05 | alternatively provide a 5..10W TX RF at 14MHz. I guess you'll run into serious trouble with that concept eventually |
| 23:23.04 | wpwrak | connect long cable, find a strong AM radio station, go there, wait :) |
| 23:23.08 | DocScrutinizer05 | wpwrak: (weizman) summary please! |
| 23:24.01 | wpwrak | you can measure the chip's power consumption if it's field-powered by looking at how much power it has left to respond |
| 23:24.36 | DocScrutinizer05 | well, that's sort of expected, and actually by design, exploited for modulation |
| 23:24.36 | wpwrak | then run your usual set of power analysis exploits |
| 23:25.33 | DocScrutinizer05 | again: running field-powered is a niche case which we won't forbid. We leave it up to suer to forbid that |
| 23:25.38 | DocScrutinizer05 | user* |
| 23:26.27 | DocScrutinizer05 | it's strictly limited to "no battery inserted, resp batery completely drained and user enabled NFC" scenario |
| 23:27.34 | DocScrutinizer05 | when user is afraid of a possible attack vector coming from field-powered, s/he simply doesn't use the device in that way |
| 23:28.55 | DocScrutinizer05 | can we get over it now? |
| 23:29.00 | wpwrak | yeah, just an effect to keep in mind. well, unless NXP added suitable countermeasures |
| 23:29.41 | ds2 | nfc is ~13MHz |
| 23:30.22 | ds2 | the amount of power available from NXP seems small (would love to see docs that say otherwise). did some research on it for powering a watch |
| 23:51.42 | DocScrutinizer05 | NXP? |
| 23:52.19 | DocScrutinizer05 | you mean VDD to SIM from PN644 when in field-powered mode? |
| 23:52.32 | DocScrutinizer05 | it's actually pretty low |
| 23:52.49 | DocScrutinizer05 | (power, not Voltage) |
| 23:53.32 | DocScrutinizer05 | whatever, I doubt a NFC antenna coil can get exploited for Qi charging |
| 23:55.10 | DocScrutinizer05 | but obviously that's up to our hacker-users, since we won't provide Qi and the NFC antenna will most likely sit in battery lid anyway, next to hackerbus where you connect Qi charger. So you're free to hack up the antenna to your liking |
| 23:56.31 | DocScrutinizer05 | (NB we haven't dicided yet if we deliver any NFC antenna at all with the device. We might only provide the option by implementing the chip, leave it up to user to add the needed antenna patch. *MIGHT* I said) |
