GlobalPlatformPro icon indicating copy to clipboard operation
GlobalPlatformPro copied to clipboard

OTA mode

Open ketyi opened this issue 7 years ago • 13 comments

Are You planning to extend the operations with OTA mode also?

ketyi avatar Nov 03 '17 15:11 ketyi

Could you elaborate ?

martinpaljak avatar Nov 03 '17 17:11 martinpaljak

You mean SCP80 or SCP81? Not unless there is a good reason, such cards are not readily available for end-users and/or depend on proprietary OTA services. If you have a business case, that would be another story.

martinpaljak avatar Nov 03 '17 17:11 martinpaljak

We have got SIM cards which are accessible for app installation via OTA only (because we have got just the OTA keys). I don't know whether it's SCP-80 or SCP-81 yet :/

ketyi avatar Nov 03 '17 22:11 ketyi

It might make sense to make a dedicated terminal(provider) that implements the necessary SIM framing on top of a standard PC/SC reader, so that the rest of GP could just work.

See the DEFCON 21 talk on JavaCard-s and SIM cards.

martinpaljak avatar Nov 06 '17 03:11 martinpaljak

Yes yes. They implemented it (wrapping APDUs into SMS-PP) in Python: https://github.com/Shadytel/sim-tools/blob/master/shadysim/shadysim.py

ketyi avatar Nov 06 '17 15:11 ketyi

Any plans with this?

martinpaljak avatar Jan 17 '18 10:01 martinpaljak

Hello Martin, Any plan to enhance with SCP80 in your java pro ? We have real use case to do this.

DeepakArya83 avatar Aug 12 '18 16:08 DeepakArya83

@DeepakArya83 see https://github.com/martinpaljak/GlobalPlatformPro/issues/91#issuecomment-341772113

martinpaljak avatar Aug 13 '18 13:08 martinpaljak

Hello Martin Yes i have seen #91...my point is we have trillions of SIM using worldwide which use scp80(not scp02 or 03) and your GP tool already cover 60% of implementation of scp80 so we have the valid reason to extend it. I can provide support on this if you allow me.

DeepakArya83 avatar Aug 13 '18 16:08 DeepakArya83

If you have a real use case and real budget behind it, feel free to contact via e-mail.

martinpaljak avatar Aug 20 '18 19:08 martinpaljak

Just my 5 cents because I have implemented this already. What the GP specification 2.x is providing is far away from 60%. Only the crypto primitives are maybe similar, but I'm not even sure here. Because all SCP have the SCP in its name it does not mean that SCP80 is 60 % of SCP02.

Actually SCP80 is coming from a different organization (ETSI). Only SCP81 is coming from GP again. For SCP 80 ETSI 102225 and ETSI 102226 (secure packets) and SMS-PP in addition must be implemented. The different data format here can be time consuming. The GSM 03.48 library available in GitHub gives at least the secured packets here. For SCP 81 the GP RAM spec. must be implemented which is using TLS and HTTP. In addition to open such a channel some CAT command leveraging the bearer independent protocol (BIP) must be used. For this knowledge and parts of ETSI 131 111 and ETSI 102 223. I would assume that 2-3 months of effort might be not unrealistic if already familiar with all of this.

koh-osug avatar Jun 23 '19 13:06 koh-osug

@koh-osug You mentioned for SCP81 (RAM), one should use CAT over BIP to trigger an open channel? Based on ETSI 102 226, there are two options, request for CAT_TP link establishment or request TCP Connection but you mentioned the former, does it mean the latter option won't work?

shokuie avatar Jun 17 '20 05:06 shokuie

This should also work. ETSI TS 102 226 defines in section "9.1 Push command behaviour" ways to open a channel. CAT stands in the former comment for card application toolkit.

koh-osug avatar Jun 17 '20 12:06 koh-osug