Google Summer of Code 2022: Uptane projects

Main GSoC Linux Foundation page: How to apply, deadlines, other workgroups, ...

What is Uptane?

Uptane, a Linux Foundation Joint Development Foundation project, is an open source, compromise-resilient software update system for vehicles. It uses layered defense mechanisms so would-be attackers need to overcome a hierarchy of access levels in order to do serious harm. By building these multiple levels into the security system, damage from any incursions—such as attackers compromising servers, bribing operators, or gaining access to vehicular networks—will be limited in how much damage they can cause. The Uptane framework is flexible and can be incorporated into the types of software update strategies already in use in the auto industry. Among other adoptions, Uptane is incorporated into the security programs of Automotive Grade Linux through the HERE actualizr program.

Initially developed under a grant from the U.S. Department of Homeland Security, Uptane was created by a team of researchers from the New York University Tandon School of Engineering in Brooklyn, NY, the University of Michigan Transportation Research Institute in Ann Arbor, MI, and the Southwest Research Institute in Austin, TX. It was formally standardized under a non-profit consortium called the Uptane Alliance on July 31, 2019, under the auspices of the IEEE/ISTO Federation. Uptane will be releasing V.2.0.0 of its Standard In early 2022.

Uptane website: https://uptane.github.io/

GitHub repository/code base: https://github.com/uptane/

Mailing list: uptane@googlegroups.com

Mentors: Lois A DeLong (lad278 at nyu dot edu), TBA

All projects are intended as full-time (3-month, 350 hours).

The Uptane project has an open-source, scalable, high-performance Uptane server implementation. Originally developed by Advanced Telematics Systems (now HERE), it is a collection of microservices written in Scala and BSD licensed. However, there’s one big problem: it’s not that easy to run. There are several reasons for this:

• It’s a collection of microservices, designed to scale big. You need to do some service orchestration (k8s recommended) to run it. There are public helm charts and k8s configs, but they’re not maintained very actively, or tested automatically as services change.
• Its internal APIs are mostly undocumented or poorly documented. To figure things out, you have to go read the source code.
• Currently, no open-source UI that is being maintained. The HERE UI for OTA Connect used to work, but the company eventually decided to stop maintaining and testing the Community Edition UI. As a consequence, the HERE UI is still public and open source, but it assumes the presence of some closed-source, HERE-internal services. As a result, it no longer works with a deployment of just the public open-source services

This situation wasn’t a problem when a developer could easily create an account on HERE’s OTA Connect service, and use libaktualizr with that. But since that service is sunsetting, it’s no longer easy for an individual developer to make use of Uptane, be it for an early-stage automotive project using Automotive Grade Linux or just for an IoT project. The open-source community will benefit from having access to a high-quality, usable Uptane implementation.

This GSoC project would be to revive and release OTA Community Edition, so that it’s actually possible/reasonable for an individual developer or a small development team to spin up their own Uptane server instance. That would include working on the ota-community-edition repository and the startup scripts/helm charts therein, and writing documentation of the APIs needed for standard Uptane flows. It could also potentially combine several (or all) of the current microservices into a pseudo-monolith to make it easier to run in situations where scaling isn’t important.

With libaktualizr and the meta-updater Yocto layer, it’s pretty easy to get an Uptane client into an IoT device, and to securely update the root filesystem using libostree. However, an important problem remains: protecting the integrity of the filesystem after it’s been deployed. With a traditional approach, where the entire partition image is flashed on the device (often with an A/B partition scheme), dm-verity is usually used to verify the integrity at the block level, at runtime. Unfortunately, this approach is incompatible with OSTree, which operates at the filesystem level. On the other hand, approaches using the Linux kernel’s Integrity Measurement Architecture (IMA) should be possible—in particular, leveraging the IMA-appraisal extension for remote attestation of the authenticity of the measured files.

There are potentially several challenges to tackle here, and some open questions:

• Challenge: Integrating IMA signatures in OSTree targets. This will likely require some work inside libostree to directly integrate there, but might be possible to do via Uptane metadata.
• Open question: How should the IMA signing key be rotated? If the IMA signing pubkey is included in the FIT image (as recommended in the EVM docs), changing it would change the root hash of the OSTree image, meaning the IMA signing key is bound to a particular target. Thus, it can’t be meaningfully rotated by Uptane. That’s probably okay, though.
• Challenge: Signing IMAs for OSTree objects and their metadata at build time, as part of Yocto bitbake (work to be done in meta-updater)
• Challenge: Signing the FIT image that the Yocto/OSTree build process generates at build time so it can be trusted by the 2nd-stage bootloader (e.g. Fedora Shim).

The Uptane website at https://uptane.github.io/ went live in January of 2019. Built on essentially the same structure as the website for its parent project, The Update Framework, it’s a serviceable website with quite a bit of information. Three years later, though, it’s apparent that the manner in which that material is arranged could use some serious modifications. In particular, we are concerned that someone new to Uptane might not be able to find the basic information it needs to consider adoption or integration.

We are looking for someone who can “deconstruct” the website in terms of layout and design to create a better information flow for users. While a cleaner and more contemporary look is desirable, we are mostly seeking a more logical arrangement of information.

In achieving this goal, the contributor could consider:

• The platform
• The overall design including typeface and color choice
• Organization of content, including determining key information that may be missing
• Dynamic elements that could be added to support more interactivity between users and the site.

You can review the current code for the layout at https://github.com/uptane/uptane.github.io.