Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OTA mode #91

Open
ketyi opened this issue Nov 3, 2017 · 13 comments
Open

OTA mode #91

ketyi opened this issue Nov 3, 2017 · 13 comments

Comments

@ketyi
Copy link

ketyi commented Nov 3, 2017

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

@martinpaljak
Copy link
Owner

Could you elaborate ?

@martinpaljak
Copy link
Owner

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.

@ketyi
Copy link
Author

ketyi commented Nov 3, 2017

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 :/

@martinpaljak
Copy link
Owner

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.

@ketyi
Copy link
Author

ketyi commented Nov 6, 2017

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

@martinpaljak
Copy link
Owner

Any plans with this?

@DeepakArya83
Copy link

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

@martinpaljak
Copy link
Owner

@DeepakArya83 see #91 (comment)

@DeepakArya83
Copy link

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.

@martinpaljak
Copy link
Owner

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

@koh-osug
Copy link

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.

@shokuie
Copy link

shokuie commented Jun 17, 2020

@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?

@koh-osug
Copy link

koh-osug commented Jun 17, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants