Instead of deleting the secret on trip, and requiring a re-arm, it could instead derive a new secret on trip, by e.g. hashing the previous secret. That way you don't have to manually re-arm it, and you get a record of all trips.
Say e.g. a bug walks in front of the camera, tripping it. Then 1 hour a later an evil maid comes in and tampers with the system. In my design, you could look at the photo record, see that the 1st trip was a false alarm, then continue looking at the data, and see that the 2nd trip was something real.
Compared to with the current design, the bug would trip it, then you would get no record of the actual evil maid. You would see the photos of the bug tripping it, and think "oh, it's just a false alarm, I don't need to worry", and trust the computer, even though it's tampered with.
Incrementing doesn't provide the security requirement here: given knowledge of a current key, it's not possible to compute a past key. With incrementing, it's easy to compute a past key. With hashing, it's not possible to compute a past key.
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.
Say e.g. a bug walks in front of the camera, tripping it. Then 1 hour a later an evil maid comes in and tampers with the system. In my design, you could look at the photo record, see that the 1st trip was a false alarm, then continue looking at the data, and see that the 2nd trip was something real.
Compared to with the current design, the bug would trip it, then you would get no record of the actual evil maid. You would see the photos of the bug tripping it, and think "oh, it's just a false alarm, I don't need to worry", and trust the computer, even though it's tampered with.