←back to thread

Show HN: Tripwire: A new anti evil maid defense

(github.com)
81 points DoctorFreeman | 2 comments | 11 Dec 25 09:46 UTC | HN request time: 0.521s | source

If you have heard of [Haven](https://github.com/guardianproject/haven), then Tripwire fills in the void for a robust anti evil maid solution after Haven went dormant.

The GitHub repo describes both the concept and the setup process in great details. For a quick overview, read up to the demo video.

There is also a presentation of Tripwire available on the Counter Surveil podcast: https://www.youtube.com/watch?v=s-wPrOTm5qo

Show context
Thorrez ◴[12 Dec 25 18:07 UTC] No.46246795[source]▶
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.

replies(2): >>46251957 #>>46265689 #
1. DoctorFreeman ◴[13 Dec 25 04:22 UTC] No.46251957[source]▶
That is honestly a fantastic idea. Many thanks for it. And I don't see any problems to fit it into the design right now.
replies(1): >>46254299 #
2. Thorrez ◴[13 Dec 25 13:13 UTC] No.46254299[source]▶
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.