Feature: Provide signed releases of OMNT

[laf0rge]

IMHO, it would be useful if you'd be releasing official builds with a known/documented signer key.

This way, for example, sysmocom could pre-install a related ARA rule to the ARA-M applet on future manufacturing batches of sysmoEUICC1 or sysmoISIM products.

Even without such "factory pre installation of an access rule", for most users it would be easier to just add the access rule (copy+pasted from the documentation here) rather than for everyone to self-sign their apks.

Yes, I understand, actual developers who do [want to] modify OMNT will of course need to sign their custom builds. But I would exepct a large number of poeple just want to use it.

[derpeter]

Thanks for your feedback.

The release apks are (or at leas should be, i will check that again) signed with the key used in the example in the documentation.
I will update the documentation to make this more clear.

regarding adding the fingerprint per default to sysmosims we might want to establish a process where the key material for signing is also in the hands of sysmocom. On the one hand this way you can sign also other apps and make sure the key is not missused.

We could than either only release those or have an additional "-sysmocom-signed" apk.

[laf0rge]

The release apks are (or at leas should be, i will check that again) signed with the key used in the example in the documentation. I will update the documentation to make this more clear.

Ah, thanks for the explanation. It wasn't immediately obvious at least to me.

regarding adding the fingerprint per default to sysmosims we might want to establish a process where the key material for signing is also in the hands of sysmocom.

That's a nice idea; in fact for the sysmoEUICC1 we already put a sysmocom specific signer key on the ARA-M in the ISD-R. However, we currently also include the digest of the keys used to sign CoIMS, which is not even FOSS.

On the one hand this way you can sign also other apps and make sure the key is not missused.

Well, yes and no. For an APK distributed outside of the play store, yes. For the play store, as you certainly know, you actually upload the private key to google and they sign it "on your behalf" so it's completely backdoored and open to any kind of misuse.

We could than either only release those or have an additional "-sysmocom-signed" apk.

If the goal is really to have sysmocom as gatekeeper/trust anchor, then sysmocom would have to do the signing in some sysmocom CI. But given that we currently don't have any CI builder for android packages (we don't do android development), I'm not sure what a time sink it is setting all this up.

[PeterHasse]

The release apks are (or at leas should be, i will check that again) signed with the key used in the example in the documentation. I will update the documentation to make this more clear.

Ah, thanks for the explanation. It wasn't immediately obvious at least to me.

regarding adding the fingerprint per default to sysmosims we might want to establish a process where the key material for signing is also in the hands of sysmocom.

That's a nice idea; in fact for the sysmoEUICC1 we already put a sysmocom specific signer key on the ARA-M in the ISD-R. However, we currently also include the digest of the keys used to sign CoIMS, which is not even FOSS.

we have now finished porting our CI pipline from gitlab to github actions. There fore the the key we use is now in the github storage aka Microsofts Hands. We could add a second key which we then share with sysmocom or we could give you access / import your key. It seems we have no way to keep the keys private (as in not accessible to github staff) without breaking the CI. On the other hand users concert by this can always build and sign them self.

On the one hand this way you can sign also other apps and make sure the key is not missused.

Well, yes and no. For an APK distributed outside of the play store, yes. For the play store, as you certainly know, you actually upload the private key to google and they sign it "on your behalf" so it's completely backdoored and open to any kind of misuse.

Thats sadly true. On the other hand if the play store is installed google does not relay need to backdoor apps ... the backdoor is build in already.

We could than either only release those or have an additional "-sysmocom-signed" apk.

If the goal is really to have sysmocom as gatekeeper/trust anchor, then sysmocom would have to do the signing in some sysmocom CI. But given that we currently don't have any CI builder for android packages (we don't do android development), I'm not sure what a time sink it is setting all this up.

My main goal would be to make it as easy as possible for users to get their setup working. So having a key preinstalled in sysmocom UICCs and eUICCS would be cool. Its your / sysmocoms decision how we proceed (or if). I would love to have a "get your eUICC with preinstalled key" here button at some point :-)

[PeterHasse]

Moving closer to 38c3 i was wondering if want to do some decisions here. Currently we still sign the apk with our own key which is on all the simcards made for the last camp. Did you @laf0rge have come to a conclusion if we should add a second release apk signed with an osmocom key / or a key we share with osomocom?
Of course I'm also looking in the direction of eUICCS from sysmocom :-)

[laf0rge]

Did you @laf0rge have come to a conclusion if we should add a second release apk signed with an osmocom key / or a key we share with osomocom?

We (@sysmocom) are currently setting up CI for building android projects (such as the new Android remote APDU proxy that @pmaier-sysmo has developed), and as part of that will also be publishing signed releases using a sysmocom release key; the one whose certificate is already on the sysmoISIM + sysmoEUICC card products.

The signing of those APKs will intentionally not be done automatically as that would require having the singer key 24/7 available somewhere on an automated system. Instead our CI will build unsigned APKs, and we can then manually sign + publish such builds.

@osmith42 is working on the above.

Once the above is done, we are also exploring the idea of publishing our own repository for F-Droid, containing [at leat initially]

• the above-mentioned remote APDU proxy
• the sysmocom-patched (SGP.26-enabled) EasyLPAC
• OMNT

[hajoha]

@laf0rge @osmith42 any updates? Anything we need to help you with? We would be still interested in the topic.

[osmith42]

Scripts for setting up an F-Droid repository with OMNT, android-apdu-proxy and easyuicc, and resigning the official apks with the mentioned key have been developed some months ago (https://gitea.osmocom.org/osmocom/osmocom-android-binaries). In theory it is ready to be published, but unfortunately too many other things came up so this hasn't been done yet.

[derpeter]

Scripts for setting up an F-Droid repository with OMNT, android-apdu-proxy and easyuicc, and resigning the official apks with the mentioned key have been developed some months ago (https://gitea.osmocom.org/osmocom/osmocom-android-binaries). In theory it is ready to be published, but unfortunately too many other things came up so this hasn't been done yet.

Oh wow thats amazing. Regarding F-Droid I'm not sure how useful a private repo will be in the future. I'm currently (like i started yesterday) implementing an update mechanism that checks against the github API and downloads the new release from there. I could make the URL configurable so one could set its own fork / server as a source. As signatures are checked by the android packet installer on each update this seem not less secure then running a private fdroid repo. But of course github sees the requests so privacy wise there is still a down side. The main reason i settled with this solution is that it will not require people to install fdroid to work.

Bringing OMNT to the official F-droid repo is still on my roadmap. I see the biggest advantage here that F-droid users can search and find OMNT and also don't need to trust another source.

I also had quick chat with dexter on integrating apu-proxy in OMNT a while back but i forgot the pro and cons we identified. Would be very interested in your view on that.