Prevent session key from being swapped to disk?

[kmcallister]

If the memory page holding Mosh's session key is swapped to disk, a copy of that key could persist indefinitely. Here's an attack scenario where this matters.

• I'm using Mosh at the airport over public WiFi. At some point mosh-client is swapped out to disk.
• Thugs from a rival yakuza clan capture my encrypted Mosh traffic.
• I shut down my laptop before going through security.
• The thugs steal my laptop from the security checkpoint.
• They recover my Mosh session key from swap and decrypt the captured session.

Using POSIX mlock, we can prevent this data from being swapped out. But there are some reasons why we might not bother.

• I usually suspend to disk rather than halting the machine. Mosh's features encourage this behavior. mlock does nothing to protect suspended data.
• I have encrypted swap, which protects both suspend-to-disk and online swapping. Full-disk encryption is a common configuration, supported by installers for Debian, Ubuntu, Fedora, etc. Users who care about this kind of attack will likely use it.
• If you're worried about targeted physical theft, you have many other concerns, including cold boot attacks and plain old beatings. A merely opportunistic laptop thief is unlikely to scan the swap partition for Mosh datastructures, let alone have access to a recording of the corresponding encrypted session.

Having established that the benefits of mlock are real but limited, what are the drawbacks?

• Most importantly, it increases complexity in a security-critical region of code.
• While mlock is available on Linux and OS X, it is not required on every POSIX platform, as it's part of the Realtime Extension.
• The amount of locked memory is limited by RLIMIT_MEMLOCK. This wil be (mis)configured to 0 on some systems, breaking Mosh.

From a cursory search, neither OpenSSH nor OpenSSL prevents swapping of cryptographic materials (which is surprising, because unlike Mosh they also handle persistent keys). By contrast, GnuPG includes a custom secure allocator with knowledge of many Unixes.

Perhaps the right solution is to call mlock if it is available, and treat failure as a non-fatal condition. But I'm still worried about increased code complexity, versus the limited enhancement to security. Maybe I should just write the code and see how complex it is.

Thoughts?

[keithw]

Perhaps the best solution would be to use a public-key-based technique to have mosh rekey every 10 minutes or something (overwriting the old key from memory). That way the yakuza will only be able to get the most recent 10 minutes of traffic.

[kmcallister]

I don't think that helps very much. mosh-client could get swapped several times to several different disk blocks, each retaining a record of the session key at that moment.

Rekeying might be a good idea in general, but it would complicate the crypto story significantly, so I am skeptical. A paranoid user of Mosh (+ screen or tmux) already has a simple way to rekey at any time.

[kmcallister]

I think the marginal security from using mlock is not worth the added complexity. So this is resolved to my satisfaction.