Core systems vulnerability with certificate authority

[eudyptula]

I suspect that the on-boarding procedure will fix this in the future, but we should be aware of a potential vulnerability between the core systems and the certificate authority (CA) until then:

1. Any application system (trustful or not) can obtain a cloud-signed certificate from the CA. This is so by design.

2. They cannot interact with other application systems, as they required a valid token and thereby an entry in the authorisation table (token based security). This is good.

3. The core systems is however based on certificate security. This means that any application system from 1. can interact freely with all the core systems. For example, I presume they can unregister any service from the service registry. This is bad.

It should be noted that the user currently have to deliberately start the CA in insecure mode for these statements to hold, see Issue #22. Per default the CA would deny any signing request from parties which are not already in possession of a signed certificate.

BTW. haven't tested any of the statements above, so they are currently just my assumptions.

[uzoltan]

Ideally the CA will have a list of issued certificates, and will not allow issuing certificates with a common name which are already in use (not without certificate revocation at least).

[hegeduscs]

Hi!

1. The CA will be hidden by a Bootstrapper core system that will have the cert accept-all interface for device secondary bootloaders. The assumption is that Arrowhead Devices will have TPMs and root certs issued by their manufacturer. This Boostrapper module will be the access point into the local cloud, and will do the boostrapping process. It will forward the CSR (after admission control crosscheck) to the CA and pass back the result. This Boostrapper will interact during bootstrapping with the System and Device Registries (and maybe the Authorization) to crosscheck its manufacturer certificate of the bootloader of the device, and check whether the given application system module/firmware/container can be started or not.

The CN structure identifies app systems. One device can host multiple app systems. One device should consist of a second stage bootloader/container manager (Docker) / OS. During bootstrapping, we are itneracting with the bootloader, and allow and help it to start or stop given app system software.

2. Yes, intentionally.

3. No, AppSys-s can only register or delete services that are theirs (crosschecked with their Arrowhead cert CN).

+1 All app systems can interact with the supporting core systems (except Gatekeeper), but cannot have direct access to the Authorization (service consumption authorization is done during orchestration). The SR and Orch are free to be accessed by all app systems.

[uzoltan]

3) I think Thomas meant that right now nothing stops application systems to get a certificate with a core system common name, thus able to delete services.

[hegeduscs]

Yes, right now, without the Boostrapper, this can happen.

The cert mgmt issues are not fully covered yet, the CA implementation is part of a POC demo with FHB at the moment.

[eudyptula]

3. Actually, didn't think about the CN check, but at least it makes it less likely to happen. I mentioned the issue mostly as an informational one - and so we would remember to check whether it was still the case after the inclusion of the proper Bootstrapper.

+1 Actually the SR is not free, see ServiceRegACF.java:52:

    } else if (requestTarget.endsWith("query")) {
      String[] allowedCoreSystems = {"orchestrator", "gatekeeper", "certificateauthority", "certificate_authority"};
      for (String coreSystem : allowedCoreSystems) {
        if (clientCN.equalsIgnoreCase(coreSystem + "." + serverFields[1])) {
          return true;
        }
      }
    }

Update: Linked the wrong code the first time around...

[hegeduscs]

Yes, the HTTPS interface of the SR is not free. But querying the DNS through DNS protocol is not secured...