Osmo-smdpp and GSMA SAS-SM accreditation

Hello, I am carrying over our discussion from the pysim issues website. @laforge you said that osmo-smdpp will never be able to be GSMA accredited. But in pysim/docs/osmo-smdpp.rst you write at the very bottom:

Hypothetically, osmo-smdpp could also be operated with GSMA production certificates, but it would require that somebody brings the code in-line with all the GSMA security requirements (HSM support, …) and operate it in a GSMA SAS-SM accredited environment and pays for the related audits.

If we have HSM support implemented and we operate it in a GSMA SAS-SM accredited environment and we pay for the related audits, what else needs to happen? Is it actually impossible or is your documentation correct?

The section you are overlooking is the require that somebody brings the code in-line with all the GSMA security requirements and the hypothetically part.

In reality, those requirements affect all parts of the software, including the fundamental software architecture. osmo-smdpp is a proof-of-concept in python. It works well for lab and research use cases. For a production deployment, you’d want an ES2+ interface, you’d want multi-tenant (multi-MNO) capability. You’d also want massive scalability, as the minimum annual audiot costs are in the order of EUR 17k (if I remember correctly). Plus the HSM etc. - nobody will spend that amount of money on software that can only handle verey few eSIM profile downloads.

So all in all, it’s easier to re-write with the SAS-SM requirements in mind, and have a proper, scalable implementation. Also note that probably 80% of the SAS-SM requirements don’t affect the software, but your business processes, the staff you hire, the physical access control of the data centre, the lack of remote shell access to the system, etc.

There’s nothing wrong with this. Many software projects start with a proof-of-concept into which limited effort is invested, only to then do a proper implementation as a second step.

I see, thank you for the insight! Putting costs aside and say I just want to get an SMDP server running for just a few eSIM profile downloads. If we have HSM support, what else is actually needed? You said “HSM etc.” and I was wondering what you meant by that since I’ve read many GSMA documents and I can’t find what else is needed on the software side (besides hosting these services on a GSMA accredited cloud provider like Azure). On the physical side, yes you’re completely right I’ve seen many requirements on that front. And also why is an ES2+ interface needed for multi-tenant capability? Again, say the end goal is to get GSMA accredited for a few profiles (without caring about cost).

I think the best document to study to get an idea about the actual requirements on both business processes, software design and also even operational aspects is GSMA FS.18 “SAS Consolidated Security Requirements”.

ES2+ is part of SGP.21/22 and hence part of the functionality that a SM-DP+ needs to provide. You won’t get SAS-SM accreditation without it. Doesn’t matter if you personally need it or not. The GSMA specs are written with a SM-DP+ operator in mind that offers services to various (GSMA member) MNOs/MVNOs. And the security requirements exist primarily to make sure that the key materials of those MNOs/MVNOs are processed in a secure way, to avoid leakage of operator confidential key materials which could be used for SIM cloning, etc.

Are these profiles issued by strong partners (MNO) of yours? That would agree to withdraw some of their usual security requirements for you, as well as their control of their profiles (it is the purpose of ES2+). Part of GSMA SAS SM includes risk assessment so, if your service :

  • doesn’t intent to address mass market,
  • includes waiver from your MNO partners about the fact that control and leaks of credentials is not critical (the volume of subscription you issue will be key, it shall be low),
  • the SLA to users is accepted to be low, with no risk for your company.
    …then there could be a way to get certified despite the limited robustness of osmo-smdpp.
    Saving on software is not the only part… It will still cost you a lot:
  • Certification is expensive (Azure is covering barely 10% of the FS.18 constraints),
  • you still need significant staff (for the sake of segregation od duty)
  • you need many security policies and procedures…
    It all depends on the purpose of your project, and ROI.
    Have you thought about working with existing vendors? Some can offer a cheap tenancy and do all the security hassle for you.
    Greg

Dear @g.bussard - your arguments in favor of SaaS only hold true in so far as anyone actually is able to (and feels confiden in) using SaaS. There are many situations where policy or other constraints prefer or even mandate the complete ownership of the full software stack, and a situation where cryptographic key material of subscribers is required to be disclosed to a third party.

I’m personally actually rather happy to hear about people (operators) who have a strong need to own and operate their entire stack as opposed to creating dependencies (and information leakage) to third parties. Self-hosting can provide much higher security (and confidence therein) than using SaaS of a third party.

In my opinion, SaaS doesn’t solve the security hassle for you. It in fact introduces a security hassle and juts unburdens you from having to deal with the SAS-SM compliance inhouse. Also keep in mind that SAS-SM compliance (and accreditation) is not equal to security. It just means you fulfill a tremendously long list of requirements in order to get the GSMA-signed certificates.