Hi all,

I'm new to this list and hope this RFC like question is fine!

From my understanding APKs security is entirely based on `libopenssl`,
used for both HTTPS in `libfetch` and for package signature validation
via public keys.

Are there any intentions or interest to allow different libraries for
either use case? I'm asking because I'd like to see APK as a replacement
for OpenWrts current package manager (`opkg`), but the libssl/libcrypto
combination is to heavy for most WiFi routers.

OpenWrt traditionally uses unencrypted HTTP to download packages and
verifies them via a `signify`[1] fork called `usign`[2]. Both public
keys and signatures are extremely small, ideal for embedded devices.

To be *OpenWrt compatible* I'd like to integrate a curve based signature
method, e.g. Ed25519 like `signify` or Curve25519/Gimli based like
`libhydrogen`[3]. The latter comes with its own secure hashing mechanism
and takes about 50Kb as a shared library.

Looking at the APK code some wrappers around the hashing/verifying could
do the trick, some `ifndef` within `libfetch` could disable HTTPS support
(and thereby lose the `libopenssl` dependency.

As v3 seems to be changing quite some things, if now is the right time
to discuss such changes.

Best,
Paul


[1]: https://www.openbsd.org/papers/bsdcan-signify.html
[2]: https://git.openwrt.org/?p=project/usign.git
[3]: https://github.com/jedisct1/libhydrogen

Hi,

On Sat, 10 Oct 2020 10:40:48 -1000
"Paul Spooren" <mail@aparcar.org> wrote:

> I'm new to this list and hope this RFC like question is fine!
> 
> >From my understanding APKs security is entirely based on
> >`libopenssl`,  
> used for both HTTPS in `libfetch` and for package signature validation
> via public keys.

Correct. openssl (or libressl) has been de facto standard for the
targets we've had so far.

> Are there any intentions or interest to allow different libraries for
> either use case? I'm asking because I'd like to see APK as a
> replacement for OpenWrts current package manager (`opkg`), but the
> libssl/libcrypto combination is to heavy for most WiFi routers.

Nice! So far our "embedded" has been low end ARMv6+ chips. Generally
RPI1/2 being the target. And in fact running apk with full alpine
indexes there is starting to be slowing down. So this was another
motivation for the v3 changes.

I understand you are interested running on even more resource
constrained environment. And I'd be happy to support where possible. I
understand this might also mean additional options to reduce index size
etc.

> OpenWrt traditionally uses unencrypted HTTP to download packages and
> verifies them via a `signify`[1] fork called `usign`[2]. Both public
> keys and signatures are extremely small, ideal for embedded devices.
> 
> To be *OpenWrt compatible* I'd like to integrate a curve based
> signature method, e.g. Ed25519 like `signify` or Curve25519/Gimli
> based like `libhydrogen`[3]. The latter comes with its own secure
> hashing mechanism and takes about 50Kb as a shared library.

Which hash? Would it make sense then to use that hash for file
integrity checks during extraction and 'audit' command?

It might make sense to make Ed25519 the default for both builds.

I assume the same crypto primitives are available also from openssl?
Preferable then the openssl would be exetended to support also these.

> Looking at the APK code some wrappers around the hashing/verifying
> could do the trick, some `ifndef` within `libfetch` could disable
> HTTPS support (and thereby lose the `libopenssl` dependency.
> 
> As v3 seems to be changing quite some things, if now is the right time
> to discuss such changes.

Yes. Thin wrappers in separate file, perhaps in the new apk_trust.h or
separate apk_crypto.h depending how much it ends up being in code lines.

Optionally disabling https in libfetch also sounds acceptable.

As noted the v3 is currently in state of flux, and I'm hoping to next
start reworking the info/search/list type applets that do read-only
operations.

So for the adb format these are welcome now. I still need let some time
to pass to see if we can make the new package format (Adb based) happen
sooner than later, and the adb changes alone would be enough. Depending
on time pressure and how things go, we can consider also amending the
current .apk format (but obviously I'd want to avoid that if possible).

Cheers,
Timo

Hi,

On Sat Oct 10, 2020 at 9:00 PM HST, Timo Teras wrote:
> > Are there any intentions or interest to allow different libraries for
> > either use case? I'm asking because I'd like to see APK as a
> > replacement for OpenWrts current package manager (`opkg`), but the
> > libssl/libcrypto combination is to heavy for most WiFi routers.
>
> Nice! So far our "embedded" has been low end ARMv6+ chips. Generally
> RPI1/2 being the target. And in fact running apk with full alpine
> indexes there is starting to be slowing down. So this was another
> motivation for the v3 changes.
>
> I understand you are interested running on even more resource
> constrained environment. And I'd be happy to support where possible. I
> understand this might also mean additional options to reduce index size
> etc.

Yes, it would be very helpful if you could give me some pointers where
other parts could be stripped down.

>
> > OpenWrt traditionally uses unencrypted HTTP to download packages and
> > verifies them via a `signify`[1] fork called `usign`[2]. Both public
> > keys and signatures are extremely small, ideal for embedded devices.
> > 
> > To be *OpenWrt compatible* I'd like to integrate a curve based
> > signature method, e.g. Ed25519 like `signify` or Curve25519/Gimli
> > based like `libhydrogen`[3]. The latter comes with its own secure
> > hashing mechanism and takes about 50Kb as a shared library.
>
> Which hash? Would it make sense then to use that hash for file
> integrity checks during extraction and 'audit' command?

I think the `libhydrogen` could be *too modern*[1], as in not trivial to
use with openssl. It's maybe more of a all or nothing approach, which
I'd be fine with, as v3 seems to change things from group up anyway.

[1]: https://github.com/jedisct1/libhydrogen/wiki/Generic-hashing#algorithm


>
> It might make sense to make Ed25519 the default for both builds.

So maybe it makes more sense to use tweetnacl[2] instead of libhydrogen.
It's also small, uses ed25519[3] and sha-512[4], would therefore be a
compatible with tools like signify and usign.

Maybe someone with more cryptographic insights should step up here and
make a statement.

[2]: https://tweetnacl.cr.yp.to/
[3]: https://nacl.cr.yp.to/sign.html
[4]: https://nacl.cr.yp.to/hash.html

>
> I assume the same crypto primitives are available also from openssl?
> Preferable then the openssl would be exetended to support also these.

Openssl does seem to support ed25519[5], however CLI support is
currently missing.

Apart from the primitives, we should agree on a key and signature
format. I'd suggest to follow the same structure as signify does[6]. 

[5]: https://www.openssl.org/docs/manmaster/man7/Ed25519.html
[6]: https://github.com/aperezdc/signify/blob/master/signify.c#L54

>
> > Looking at the APK code some wrappers around the hashing/verifying
> > could do the trick, some `ifndef` within `libfetch` could disable
> > HTTPS support (and thereby lose the `libopenssl` dependency.
> > 
> > As v3 seems to be changing quite some things, if now is the right time
> > to discuss such changes.
>
> Yes. Thin wrappers in separate file, perhaps in the new apk_trust.h or
> separate apk_crypto.h depending how much it ends up being in code lines.

I'll look into that, good pointer.

>
> Optionally disabling https in libfetch also sounds acceptable.

Great. In fact we're looking libfetch entirely with a smaller OpenWrt
libary, but that shouldn't be scope of this thread.

>
> As noted the v3 is currently in state of flux, and I'm hoping to next
> start reworking the info/search/list type applets that do read-only
> operations.
>
> So for the adb format these are welcome now. I still need let some time
> to pass to see if we can make the new package format (Adb based) happen
> sooner than later, and the adb changes alone would be enough. Depending
> on time pressure and how things go, we can consider also amending the
> current .apk format (but obviously I'd want to avoid that if possible).

I looked shortly into that and we could simply add another signature in
the format `.SIGN.SIGNIFY.<fingerprint>.sig`. But as the whole migration
process within OpenWrt takes easily a year, I'd focus on v3 only.

Best,
Paul

On Sat, 10 Oct 2020 21:49:11 -1000
"Paul Spooren" <mail@aparcar.org> wrote:

> On Sat Oct 10, 2020 at 9:00 PM HST, Timo Teras wrote:
> > > Are there any intentions or interest to allow different libraries
> > > for either use case? I'm asking because I'd like to see APK as a
> > > replacement for OpenWrts current package manager (`opkg`), but the
> > > libssl/libcrypto combination is to heavy for most WiFi routers.  
> >
> > I understand you are interested running on even more resource
> > constrained environment. And I'd be happy to support where
> > possible. I understand this might also mean additional options to
> > reduce index size etc.  
> 
> Yes, it would be very helpful if you could give me some pointers where
> other parts could be stripped down.

That really depends on what requirements you have. We can consider
making optional everything that is considered extra (e.g. not needed
for package dependencies or installation). Could include
description, maintainer, origin, reference urls, etc. Or is some of
this something you need to display somewhere?

> I think the `libhydrogen` could be *too modern*[1], as in not trivial
> to use with openssl. It's maybe more of a all or nothing approach,
> which I'd be fine with, as v3 seems to change things from group up
> anyway.
> 
> [1]:
> https://github.com/jedisct1/libhydrogen/wiki/Generic-hashing#algorithm
> 
> > It might make sense to make Ed25519 the default for both builds.  
> 
> So maybe it makes more sense to use tweetnacl[2] instead of
> libhydrogen. It's also small, uses ed25519[3] and sha-512[4], would
> therefore be a compatible with tools like signify and usign.
> 
> Maybe someone with more cryptographic insights should step up here and
> make a statement.
> 
> [2]: https://tweetnacl.cr.yp.to/
> [3]: https://nacl.cr.yp.to/sign.html
> [4]: https://nacl.cr.yp.to/hash.html

I have currently no strong opinion what the alternative library should
be. As long as it satisfied your size requirement and is suitable
enough API to be usable in the current code base without major
refactoring.

> > I assume the same crypto primitives are available also from openssl?
> > Preferable then the openssl would be exetended to support also
> > these.  
> 
> Openssl does seem to support ed25519[5], however CLI support is
> currently missing.

Yes.

> Apart from the primitives, we should agree on a key and signature
> format. I'd suggest to follow the same structure as signify does[6]. 
> 
> [5]: https://www.openssl.org/docs/manmaster/man7/Ed25519.html
> [6]: https://github.com/aperezdc/signify/blob/master/signify.c#L54

Currently key generation is not in scope for apk. And I think I would
like to keep it like that. Make apk use keys generated by other tools

We could fairly easily support multiple key formats if needed. But
currently it's using openssl pkey infrastructure to load PEM private
keys which seems to be fairly standard solution. I think adding support
for signify keys should not be a problem.

However, the signatures are embedded as part of the file structures, so
trying to make them compatible when you cannot anyway use the external
tool sounds little bit unnecessary complication. The code for adb
signatures has already been written. But if there's strong(er) reasons
to adjust that, it is still possible.

> >  
> > > Looking at the APK code some wrappers around the hashing/verifying
> > > could do the trick, some `ifndef` within `libfetch` could disable
> > > HTTPS support (and thereby lose the `libopenssl` dependency.
> > > 
> > > As v3 seems to be changing quite some things, if now is the right
> > > time to discuss such changes.  
> >
> > Yes. Thin wrappers in separate file, perhaps in the new apk_trust.h
> > or separate apk_crypto.h depending how much it ends up being in
> > code lines.  
> 
> I'll look into that, good pointer.
> 
> >
> > Optionally disabling https in libfetch also sounds acceptable.  
> 
> Great. In fact we're looking libfetch entirely with a smaller OpenWrt
> libary, but that shouldn't be scope of this thread.

Right. That may deserve it's own thread. I would be happy to look at
replacing the libfetch too. I am not full satisfied with it as-is.
Options being fixing libfetch, finding something else, or in worst case
writing something to replace it.

The history is that originally apk fork+execed wget with fallback to
busybox wget. We sought for library that would be easy enough to link
in statically and support enough of http things. We ended up with
libfetch and it's fairly ok. Though we've needed to fix certain things
in it in-tree for linux.

I think the current feature set is basic http support, https support
which should be optional, basic authentication, if-modified-since,
cache-control, netrc, connection pooling, proxy support (via
environment variables).

The things I am additional looking for are no extra memcpys, so the
data could be directly received to user given buffer when possible;
automatic retries in case of connections problems (potentially
supporting switching mirrors), proper buffering for request sending,
and potentially http/2 support.


> > As noted the v3 is currently in state of flux, and I'm hoping to
> > next start reworking the info/search/list type applets that do
> > read-only operations.
> >
> > So for the adb format these are welcome now. I still need let some
> > time to pass to see if we can make the new package format (Adb
> > based) happen sooner than later, and the adb changes alone would be
> > enough. Depending on time pressure and how things go, we can
> > consider also amending the current .apk format (but obviously I'd
> > want to avoid that if possible).  
> 
> I looked shortly into that and we could simply add another signature
> in the format `.SIGN.SIGNIFY.<fingerprint>.sig`. But as the whole
> migration process within OpenWrt takes easily a year, I'd focus on v3
> only.

Yes, I think adding the new signature in v2 packages is not problem.
Anything with new signature specifier there should be ok. I would just
like to avoid getting these package out at all if possible.

The main motivation in V3 package format is that the manifest is
signed, and the signed-manifest is directly copied to installed-db.
This allows later on 'apk audit' to verify the signatures and whole
filesystem retroactive against the original asymmetric signatures.

Timo