Android - Are Android updates signed with Google's private key or other signing techniques?
Are updates digitally signed before being shipped?
Yes, updates are cryptographically signed by the publisher. This is to ensure the integrity of the update, both from unintentional corruption during the transmission, and willful manipulation from an attacker.
Who signs the updates? Is it Google?
That depends on who publishes updates for your phone. If you own a Nexus or Pixel phone, then the update is likely published and signed by Google.
Other manufacturers, such as Samsung for instance, modify Android before shipping it. This may include their own system applications, their own launchers, etc.. In such cases, the manufacturer is the publisher of the update and thus responsible for signing it.
But isn't Google the one who develops Android?
It's not Google alone, it's the OHA - Google just happens to be their most prominent member. Furthermore, Android is Open Source, meaning that contributions come from many different companies and individuals, not just Google.
WHO SIGNS ANDROID PLATFORM COMPONENTS?
As explained very well in @MechMK1's answer, Google is the main contributor to AOSP development. But AOSP isn't the only software on Android devices, there are a number of hardware specific pieces of code. Above all there is kernel (based on AOSP's common kernel source), but that must be open-source due to GPL, so OEMs/SoC vendors are bound to release source code. However other parts, particularly userspace HALs which include a large part of hardware drivers, and the bootloader firmware which is loaded prior to kernel in boot chain are completely closed-source in most cases (intellectual property of OEM/SoC vendor). So the software on Android devices we know of is at least AOSP + kernel + HALs + bootloaders (and other SoC firmware).
OEMs get a copy of AOSP release from Google free of cost (theoretically; in actual they are bound in contracts), add their proprietary code which may also unnecessarily replace AOSP code (e.g. to change visuals) and add new apps/features, build the ROM and release that with device (or as OTA update package later on). The keys - which are used to sign system/framework apps and update package afterwards - are built/defined during ROM compiling process which is carried out by OEM, so OEM owns private keys. This ensures that core components of OS don't get any future updates from untrusted source. Mostly OEMs also add Google's proprietary Play Services and other apps (GMS) already signed with Google's private keys so that those get updates directly from Google.
ANDROID ONE:
Android One program was slightly different in the beginning. A quote from For the next five billion: Android One:
"To help ensure a consistent experience, Android One devices will receive the latest versions of Android directly from Google."
But their vision of pure Android on devices with strict hardware requirements wasn't appealing to OEMs, so within a year they had to tweak Android One strategy and the plan switched to:
"Android One phones receive the latest version of Android from Google’s hardware partners. Google’s partners send updates based on their schedule - trying to get them to you as soon as possible."
* Quoted from Google's update support page, now removed.
The long story short, OTA updates - whether related to hardware or to Android framework - come from OEMs. They build it and sign it with their keys. Google signs either OTA updates only for their own devices (e.g. Pixel), or the proprietary apps (e.g. Play Store) just like any app developer.
Also for A/B updates:
"For devices using Google's OTA infrastructure, the system changes are all in AOSP, and the client code is provided by Google Play services. OEMs not using Google's OTA infrastructure will be able to reuse the AOSP system code but will need to supply their own client."
AOSP's System Update APIs (update_engine) by-default use Google's root CA (/system/etc/security/cacerts_google) to establish https connection with (Omaha?) update server. But OEMs are free to modify the code. In each case OTA client app, system daemon and update server are managed by OEM.
VERIFIED BOOT:
On production devices release key is used to sign the update .zip file and possibly some apps as well. Its public key pair is saved on device in /system/etc/security/otacerts.zip, used to verify the cryptographic signature of update package. But additionally there is another signing mechanism available on many devices since Android 5, that is Verified Boot (dm-verity). OEMs use RSA key pair as a part of (A)VB mechanism. Private key is used to cryptographically sign the hash tree of whole /system partition, while public key (/verity_key) is stored in ramdisk (inside boot.img on non-SAR devices) or kernel's system keyring, which verifies the integrity of dm-verity mapping table (metablock) appended after last filesystem block at the end of /system partition. dm-verity table (hash tree) in turn verifies whole /system partition by matching hashes. This is to protect /system from any unintended modification by malware or user e.g. by mounting R/W.
During block-based OTA update a binary patch is applied to whole system partition block device file. This patch is generated by taking a binary difference between old and updated system.img. Updated table must be signed by the same private key owned by original ROM developer, otherwise dm-verity would fail. In the same way dm-verity protects /vendor and /odm partitions. boot and recovery are signed by another key, either manually provided or built with application bootloader or saved to some other secure location. So it's only the OEM who ensures this chain of trust during boot process, creates all of the keys initially and later on signs and sends OTA updates.