The updated Apple | Google COVID-19 exposure notification cryptography paper is here: covid19-static.cdn-apple.com/applications/c… . Going to follow up with observations as I read it.
O.k. so first off; I've seen speculation that the change from HMAC to AES is to save power. I don't think this is true. The change to AES is to allow the phone to broadcast some encrypted data (the bluetooth power level) that can later be decrypted.
The power theory is silly IMO; Bluetooth IDs are only generated 144 times a day, the battery savings would be negligible.
Broadcasting the transmit power level of the bluetooth assists the app in assessing distance. The receiving phone stores the observed signal strength on its end, and later when everything can be decrypted, it allows the system to est. the distance between the sender and receiver.
Anyway, let's get into some cryptography details! Basically every time the bluetooth MAC changes, the device produces a new identifier which an AES ECB (!!) encrypted version of the current time-internal number. Don't panic: ECB is ok here, time-intervals won't repeat.
That 16-byte encrypted blob is broadcast on the wire, but it also the IV for an AES-CTR encrypted 4 byte section of metadata. What's in the metadata? Here's the list from the Bluetooth spec. 
On the surface of it, this doesn't look safe. If the power level changes, then byte 1 will change, but get encrypted using the same key, IV pair, and broadcast. This leaks one byte of ciphertext. Since there's no MAC of any kind, it also means these values can be forged.
Like I could grab your broadcast bluetooth ID, change that byte, and rebroadcast it .. and it would decrypt and register just fine. Hard to think of a useful attack though. I can't predict the decrypted value, just corrupt it.
If I re-broadcast all 256 potential values, some would be bound to register as within the "proximity radius of danger", but it'd be an easy attack to detect.
And Apple | Google are careful not to leak the ciphertext byte. The bluetooth paper makes clear that you have to change the metadata at the same time as the key used to encrypt it (which is valid for a time interval).
On the whole, it looks ok to me if a bit precarious. If the Bluetooth MAC address changes and the key-rotations get out of phase, things go bad. If the app re-generates an ID when the power level changes, that's worse, though not the end of the world.
This all reads like a well-integrated effort by professionals working across cryptographic, radio, and epidemiological boundaries to make smart trade-offs.
Addendum: maybe the power theory isn't so silly. I forgot that the app also has to re-generate the IDs of every infected person to determine matches. AES will save a lot of power in that case.
