3 problems I can think with my idea are: (1) it makes the tripping less noisy, so it increases the chance someone might ignore or miss the trip. I guess with the right UX that can be mostly sovled. (2) if a bug walks in front of the camera, is that 1 trip or multiple trips? The bug would be visible for multiple frames, so it might do a ton of secret rotations for a single incident, which could present an odd UX to the user. (3) in the original design, there's an asymmetric key that's deleted on trip, which isn't really possible in my design. That means in the original design, if the phone is hacked, that doesn't let the attacker forge security footage, because the phone only has a public key, whereas in my design, if the phone is hacked, that does let the attacker forge security footage, because security is based on a symmetric key/secret. (One thing I don't understand about the original design is why it has both a symmetric key/secret and an asymmetric key. If they're both deleted at the same time, and don't auto-rotate, I don't see what benefit the symmetric key/secret provides.)
One idea to improve the (2) problem is to instead of only rotating the secret on trip, rotate for every frame, regardless of whether a trip is ongoing or not. So if there are 10 photos/sec that would be 10 rotations/sec. And then there can be a boolean in the signed data with each frame (signed e.g. with a MAC using the secret) that indicates whether there's an ongoing trip or not (and also include a timestamp in the signed data). So that means regardless of whether it's tripping, an attacker can never backdate images prior to when the attacker got control of the system.
alt Hacker News
3 problems I can think with my idea are: (1) it makes the tripping less noisy, so it increases the chance someone might ignore or miss the trip. I guess with the right UX that can be mostly sovled. (2) if a bug walks in front of the camera, is that 1 trip or multiple trips? The bug would be visible for multiple frames, so it might do a ton of secret rotations for a single incident, which could present an odd UX to the user. (3) in the original design, there's an asymmetric key that's deleted on trip, which isn't really possible in my design. That means in the original design, if the phone is hacked, that doesn't let the attacker forge security footage, because the phone only has a public key, whereas in my design, if the phone is hacked, that does let the attacker forge security footage, because security is based on a symmetric key/secret. (One thing I don't understand about the original design is why it has both a symmetric key/secret and an asymmetric key. If they're both deleted at the same time, and don't auto-rotate, I don't see what benefit the symmetric key/secret provides.)
One idea to improve the (2) problem is to instead of only rotating the secret on trip, rotate for every frame, regardless of whether a trip is ongoing or not. So if there are 10 photos/sec that would be 10 rotations/sec. And then there can be a boolean in the signed data with each frame (signed e.g. with a MAC using the secret) that indicates whether there's an ongoing trip or not (and also include a timestamp in the signed data). So that means regardless of whether it's tripping, an attacker can never backdate images prior to when the attacker got control of the system.