7 ms·

Shufflecake: Plausible deniability for hidden filesystems on Linux (2023)

66 points by simonpure 2y ago

3np 2y ago
Main links of interest apart from the OP research paper (https://eprint.iacr.org/2023/1529 https://eprint.iacr.org/2023/1529 / https://arxiv.org/abs/2310.04589 https://arxiv.org/abs/2310.04589): https://shufflecake.net/ https://shufflecake.net/ Project website https://codeberg.org/shufflecake/shufflecake-c https://codeberg.org/shufflecake/shufflecake-c Implementation (GPLv2) https://fosstodon.org/@shufflecake https://fosstodon.org/@shufflecake Socials https://news.ycombinator.com/item?id=33545393 https://news.ycombinator.com/item?id=33545393 Past HN submission
- dang 2y ago
  Thanks! Related: Shufflecake Research Paper Released - https://news.ycombinator.com/item?id=37822664 https://news.ycombinator.com/item?id=37822664 - Oct 2023 (1 comment) Shufflecake: Plausible deniability for multiple hidden filesystems on Linux - https://news.ycombinator.com/item?id=35621451 https://news.ycombinator.com/item?id=35621451 - April 2023 (1 comment) Shufflecake: Plausible deniability for multiple hidden filesystems on Linux - https://news.ycombinator.com/item?id=33580957 https://news.ycombinator.com/item?id=33580957 - Nov 2022 (1 comment) Shufflecake: Plausible deniability for multiple hidden filesystems on Linux - https://news.ycombinator.com/item?id=33576809 https://news.ycombinator.com/item?id=33576809 - Nov 2022 (1 comment) Shufflecake: Plausible Deniability for Multiple Hidden Filesystems - https://news.ycombinator.com/item?id=33545393 https://news.ycombinator.com/item?id=33545393 - Nov 2022 (3 comments)
mdhb 2y ago
Couple of quick thoughts here. 1. Cool project, this space always felt rather empty after the mysterious ending of TrueCrypt. 2. This was made as part of a Swiss Government tech lab’s program and requires you to install kernel drivers that were written in C. So think carefully about what you are actually doing here and if that makes sense for you or not. 3. I’m still much less clear on how it prevents this famous XKCD security problem https://xkcd.com/538/ https://xkcd.com/538/ but it seems that any system that was captured with this would be immediately obvious what was going on right down to the userland CLI tool and isn’t going to save you from getting wrenched if that’s a part of your security model, if anything you’re almost certainly going to get wrenched a LOT more unless you’re able to provide them with 15 different working passwords which is the max limit of how many “layers” this thing provides. In fact, that’s kind of at the crux of the problem here. While it seems like a great idea initially to have a system where “you can’t prove that there are any hidden files there” is actually a huge liability not the ace up your sleeve you might assume it is at first. Because let’s say you make a public, secret and top secret layer on a device with this thing. You don’t seem to be able to prove that there was ever not an ultra top secret layer so it’s going to just be you trying to convince someone when that someone might be very violent. So if a physical interrogation is a part of your threat model I’d probably say to avoid this approach entirely as it will possibly do more harm than good.
- humanfromearth9 2y ago
  With this reasoning, whether or not you actually have a hidden FS is not relevant, as it's unprovable. So you will be tortured with no end anyway just to make sure that there is no hidden FS. Because that you have a hidden FS will be the assumption of anyone thinking you are hiding something.
  - mdhb 2y ago
    I was specifically referring to a scenario where you have a device captured with these binaries on it just to be clear. At that point your day probably becomes a lot worse depending on who finds it and why they want to talk with you about it.
  - doctorpangloss 2y ago
    I don’t know a max 15 layers seems pretty clear to me. You’ll ask for 15 passwords and if not furnished, the wrench.
- tomgag 2y ago
  Hey, Shufflecake co-author here, thanks for the questions. 1. Indeed! 2. Wow wow wow, hold on there :D there is a misunderstanding, the "Swiss Government" was never involved not even remotely. First of all, this project has roots that go waaay back in time [1]. It was finally realized when I met Elia, who was then a student at a joint ETHZ/EPFL MSc program, and Elia accepted the thesis project that I proposed in the Kudelski Security Research team [2]. Kudelski Security (disclaimer: my current employer) is a traditional cybersecurity company, mainly focused on MDR, CISO-As-A-Service stuff, etc, but it's also one of the few ones which also has a dedicated fundamental research team, which I'm part of as a Principal Cryptographer. The goal of our team is not only to "invent new ways for the company to make money", but also to do "good PR", through e.g. scientific/academic publications, talks at conferences, open source software etc., all things which is what I'm personally focused on. As part of this, we offer the possibility to students to do their thesis in our team on some selected topic, and that's where Shufflecake came from. That is, originally. As it is now, Kudelski Security is not involved in Shufflecake anymore, it's basically a pet project of Elia and myself, we pay out of our pocket for website hosting, etc, and we work on Shufflecake on our spare time. So, please feel free to contribute, we need help! 3. That is exactly the point! The "killer feature" of Shufflecake is exactly that there is no way to determine when you have finished giving up all your passwords, or there is still something undisclosed. It is true that this also means that the adversary "does not know when they can stop torturing you", but we firmly believe, both as a matter of philosophy but also pragmatically, that "plausible deniability" does not make sense if you're not willing to accept this risk. Let me explain better, because this is a recurring questions we have. First of all, you have to keep in mind the security model. We are not necessarily talking about Snowden-level paranoia here, it might be something more mundane, for example an investigation in a civil court because you're suspected of being in possession of illegal material, whatever "illegal" means. At least in democratic countries, you don't risk of being waterboarded for this. We know [3] that even TrueCrypt or similar systems are enough to be acquitted in some cases. Then there are those cases where the adversary doesn't really care, they just want to find something. We recently had a discussion with a large international humanitarian organization, one of their officers told us "our agents often cross borders with laptops full of sensitive informations, in theory we are protected from searches by the UN treaty XYZ but... go to explain that to the angry Afghan guard at the airport!". Shufflecake allows to bypass this problem efficiently. And then there are those cases where you are hiding secrets that you care about more than your own life. Let's be clear: if you are an investigative journalist in Guatemala and the Cartel kidnaps you, you're dead, period. If you're a member of a resistance group of a repressed minority in a dictatorial state and the police apprehend you, you're gonna disappear, no matter what. But, with Shufflecake, you at least have the chance maybe to resist and possibly save the life of your informants or comrades. With TrueCrypt, you don't really have this option. Hope that clarifies, but feel free to ask more. Thanks! [1] (in Italian) https://e-privacy.winstonsmith.org/e-privacy-X.html#i13 https://e-privacy.winstonsmith.org/e-privacy-X.html#i13 [2] https://research.kudelskisecurity.com/ https://research.kudelskisecurity.com/ [3] https://www.theregister.com/2010/06/28/brazil_banker_crypto_lock_out/ https://www.theregister.com/2010/06/28/brazil_banker_crypto_...
tomgag 2y ago
Wow, admin of the Shufflecake project here, super excited to see this on HN again! Feel free to AMA, Elia and I are busy right now working on an upcoming major release, we will give announcement and more details at the upcoming Swiss Crypto Day event in St Gallen next Monday: https://swisscryptoday.github.io/2024/ https://swisscryptoday.github.io/2024/ I will also reply to comments below.
- chungy 2y ago
  The website mentions overcommitting volumes being an effective method of creating plausible deniability. How does Shufflecake manage used data in the volumes to make sure they don't clobber each other? Do you depend on TRIM requests coming from the file system, or is it just a matter of hoping you don't happen to cause corruption? There is a further FAQ entry about TRIM that seems more related to the underlying encryption than to file systems that live on top.
  - tomgag 2y ago
    Thanks for the question! Well, overcommitment is part of the plausible deniability design: basically we need that, whatever password secrecy level you provide, it looks like all the disk space is utilized, because if there is clearly unmapped space then it's clear that there is still something hidden. Currently, we achieve this with overcommitting the volume size: if you have, say, 1 GB device, and you format it with a 3-volume Shufflecake setup, each of these 3 volumes will appear as 1 GB in size. Then the question is, what happens if you write more than 1 GB in total? Well, you will start receiving I/O errors. Volumes themselves will not get corrupted, because they will not clobber each other, but the kernel module will basically tell you "sorry, I ran out of space earlier than I expected". A planned feature in the future, to manage this more elegantly, is to use "virtual quotas". With this system, low-secrecy volumes will have a limited size (chosen by the user), but the "topmost" unlocked volume (the "most secret one" that you have unlocked with a given password) will not have this limit: it will always appear as taking all the leftover space. See the section 6.5 "Use of Disk Metadata" in the research paper.
    - 2y ago
kkfx 2y ago
My personal dream is "more than plausible deniability", or being able to mount an encrypted fs with many keys, one show "the basic", another "some hidden but not important stuff", another the really important stuff. This way you have a clear face, a hidden but revealable one, to state that's why I use this tool, and no can say you have if also for something else. A part of a real deniability is proving why you have some code in your system.
- aidenn0 2y ago
  Shufflecake allows this; a setup almost exactly the way you mention is on their homepage: https://shufflecake.net/ https://shufflecake.net/ > In Shufflecake, each hidden volume is encrypted with a different secret key, scrambled across the empty space of an underlying existing storage medium, and indistinguishable from random noise when not decrypted. Even if the presence of the Shufflecake software itself cannot be hidden - and hence the presence of secret volumes is suspected - the number of volumes is also hidden. This allows a user to create a hierarchy of plausible deniability, where "most hidden" secret volumes are buried under "less hidden" decoy volumes, whose passwords can be surrendered under pressure.
  - tomgag 2y ago
    Yes, 100% this. And wait when we'll release a Shufflecake-powered, fully hidden multi-OS distro ;)

66 points by simonpure 2y ago

3np 2y ago

Main links of interest apart from the OP research paper (https://eprint.iacr.org/2023/1529 https://eprint.iacr.org/2023/1529 / https://arxiv.org/abs/2310.04589 https://arxiv.org/abs/2310.04589): https://shufflecake.net/ https://shufflecake.net/ Project website https://codeberg.org/shufflecake/shufflecake-c https://codeberg.org/shufflecake/shufflecake-c Implementation (GPLv2) https://fosstodon.org/@shufflecake https://fosstodon.org/@shufflecake Socials https://news.ycombinator.com/item?id=33545393 https://news.ycombinator.com/item?id=33545393 Past HN submission

dang 2y ago
Thanks! Related: Shufflecake Research Paper Released - https://news.ycombinator.com/item?id=37822664 https://news.ycombinator.com/item?id=37822664 - Oct 2023 (1 comment) Shufflecake: Plausible deniability for multiple hidden filesystems on Linux - https://news.ycombinator.com/item?id=35621451 https://news.ycombinator.com/item?id=35621451 - April 2023 (1 comment) Shufflecake: Plausible deniability for multiple hidden filesystems on Linux - https://news.ycombinator.com/item?id=33580957 https://news.ycombinator.com/item?id=33580957 - Nov 2022 (1 comment) Shufflecake: Plausible deniability for multiple hidden filesystems on Linux - https://news.ycombinator.com/item?id=33576809 https://news.ycombinator.com/item?id=33576809 - Nov 2022 (1 comment) Shufflecake: Plausible Deniability for Multiple Hidden Filesystems - https://news.ycombinator.com/item?id=33545393 https://news.ycombinator.com/item?id=33545393 - Nov 2022 (3 comments)

mdhb 2y ago

Couple of quick thoughts here. 1. Cool project, this space always felt rather empty after the mysterious ending of TrueCrypt. 2. This was made as part of a Swiss Government tech lab’s program and requires you to install kernel drivers that were written in C. So think carefully about what you are actually doing here and if that makes sense for you or not. 3. I’m still much less clear on how it prevents this famous XKCD security problem https://xkcd.com/538/ https://xkcd.com/538/ but it seems that any system that was captured with this would be immediately obvious what was going on right down to the userland CLI tool and isn’t going to save you from getting wrenched if that’s a part of your security model, if anything you’re almost certainly going to get wrenched a LOT more unless you’re able to provide them with 15 different working passwords which is the max limit of how many “layers” this thing provides. In fact, that’s kind of at the crux of the problem here. While it seems like a great idea initially to have a system where “you can’t prove that there are any hidden files there” is actually a huge liability not the ace up your sleeve you might assume it is at first. Because let’s say you make a public, secret and top secret layer on a device with this thing. You don’t seem to be able to prove that there was ever not an ultra top secret layer so it’s going to just be you trying to convince someone when that someone might be very violent. So if a physical interrogation is a part of your threat model I’d probably say to avoid this approach entirely as it will possibly do more harm than good.

humanfromearth9 2y ago
With this reasoning, whether or not you actually have a hidden FS is not relevant, as it's unprovable. So you will be tortured with no end anyway just to make sure that there is no hidden FS. Because that you have a hidden FS will be the assumption of anyone thinking you are hiding something.
- mdhb 2y ago
  I was specifically referring to a scenario where you have a device captured with these binaries on it just to be clear. At that point your day probably becomes a lot worse depending on who finds it and why they want to talk with you about it.
- doctorpangloss 2y ago
  I don’t know a max 15 layers seems pretty clear to me. You’ll ask for 15 passwords and if not furnished, the wrench.
tomgag 2y ago
Hey, Shufflecake co-author here, thanks for the questions. 1. Indeed! 2. Wow wow wow, hold on there :D there is a misunderstanding, the "Swiss Government" was never involved not even remotely. First of all, this project has roots that go waaay back in time [1]. It was finally realized when I met Elia, who was then a student at a joint ETHZ/EPFL MSc program, and Elia accepted the thesis project that I proposed in the Kudelski Security Research team [2]. Kudelski Security (disclaimer: my current employer) is a traditional cybersecurity company, mainly focused on MDR, CISO-As-A-Service stuff, etc, but it's also one of the few ones which also has a dedicated fundamental research team, which I'm part of as a Principal Cryptographer. The goal of our team is not only to "invent new ways for the company to make money", but also to do "good PR", through e.g. scientific/academic publications, talks at conferences, open source software etc., all things which is what I'm personally focused on. As part of this, we offer the possibility to students to do their thesis in our team on some selected topic, and that's where Shufflecake came from. That is, originally. As it is now, Kudelski Security is not involved in Shufflecake anymore, it's basically a pet project of Elia and myself, we pay out of our pocket for website hosting, etc, and we work on Shufflecake on our spare time. So, please feel free to contribute, we need help! 3. That is exactly the point! The "killer feature" of Shufflecake is exactly that there is no way to determine when you have finished giving up all your passwords, or there is still something undisclosed. It is true that this also means that the adversary "does not know when they can stop torturing you", but we firmly believe, both as a matter of philosophy but also pragmatically, that "plausible deniability" does not make sense if you're not willing to accept this risk. Let me explain better, because this is a recurring questions we have. First of all, you have to keep in mind the security model. We are not necessarily talking about Snowden-level paranoia here, it might be something more mundane, for example an investigation in a civil court because you're suspected of being in possession of illegal material, whatever "illegal" means. At least in democratic countries, you don't risk of being waterboarded for this. We know [3] that even TrueCrypt or similar systems are enough to be acquitted in some cases. Then there are those cases where the adversary doesn't really care, they just want to find something. We recently had a discussion with a large international humanitarian organization, one of their officers told us "our agents often cross borders with laptops full of sensitive informations, in theory we are protected from searches by the UN treaty XYZ but... go to explain that to the angry Afghan guard at the airport!". Shufflecake allows to bypass this problem efficiently. And then there are those cases where you are hiding secrets that you care about more than your own life. Let's be clear: if you are an investigative journalist in Guatemala and the Cartel kidnaps you, you're dead, period. If you're a member of a resistance group of a repressed minority in a dictatorial state and the police apprehend you, you're gonna disappear, no matter what. But, with Shufflecake, you at least have the chance maybe to resist and possibly save the life of your informants or comrades. With TrueCrypt, you don't really have this option. Hope that clarifies, but feel free to ask more. Thanks! [1] (in Italian) https://e-privacy.winstonsmith.org/e-privacy-X.html#i13 https://e-privacy.winstonsmith.org/e-privacy-X.html#i13 [2] https://research.kudelskisecurity.com/ https://research.kudelskisecurity.com/ [3] https://www.theregister.com/2010/06/28/brazil_banker_crypto_lock_out/ https://www.theregister.com/2010/06/28/brazil_banker_crypto_...

tomgag 2y ago

Wow, admin of the Shufflecake project here, super excited to see this on HN again! Feel free to AMA, Elia and I are busy right now working on an upcoming major release, we will give announcement and more details at the upcoming Swiss Crypto Day event in St Gallen next Monday: https://swisscryptoday.github.io/2024/ https://swisscryptoday.github.io/2024/ I will also reply to comments below.

chungy 2y ago
The website mentions overcommitting volumes being an effective method of creating plausible deniability. How does Shufflecake manage used data in the volumes to make sure they don't clobber each other? Do you depend on TRIM requests coming from the file system, or is it just a matter of hoping you don't happen to cause corruption? There is a further FAQ entry about TRIM that seems more related to the underlying encryption than to file systems that live on top.
- tomgag 2y ago
  Thanks for the question! Well, overcommitment is part of the plausible deniability design: basically we need that, whatever password secrecy level you provide, it looks like all the disk space is utilized, because if there is clearly unmapped space then it's clear that there is still something hidden. Currently, we achieve this with overcommitting the volume size: if you have, say, 1 GB device, and you format it with a 3-volume Shufflecake setup, each of these 3 volumes will appear as 1 GB in size. Then the question is, what happens if you write more than 1 GB in total? Well, you will start receiving I/O errors. Volumes themselves will not get corrupted, because they will not clobber each other, but the kernel module will basically tell you "sorry, I ran out of space earlier than I expected". A planned feature in the future, to manage this more elegantly, is to use "virtual quotas". With this system, low-secrecy volumes will have a limited size (chosen by the user), but the "topmost" unlocked volume (the "most secret one" that you have unlocked with a given password) will not have this limit: it will always appear as taking all the leftover space. See the section 6.5 "Use of Disk Metadata" in the research paper.
  - 2y ago

kkfx 2y ago

My personal dream is "more than plausible deniability", or being able to mount an encrypted fs with many keys, one show "the basic", another "some hidden but not important stuff", another the really important stuff. This way you have a clear face, a hidden but revealable one, to state that's why I use this tool, and no can say you have if also for something else. A part of a real deniability is proving why you have some code in your system.

aidenn0 2y ago
Shufflecake allows this; a setup almost exactly the way you mention is on their homepage: https://shufflecake.net/ https://shufflecake.net/ > In Shufflecake, each hidden volume is encrypted with a different secret key, scrambled across the empty space of an underlying existing storage medium, and indistinguishable from random noise when not decrypted. Even if the presence of the Shufflecake software itself cannot be hidden - and hence the presence of secret volumes is suspected - the number of volumes is also hidden. This allows a user to create a hierarchy of plausible deniability, where "most hidden" secret volumes are buried under "less hidden" decoy volumes, whose passwords can be surrendered under pressure.
- tomgag 2y ago
  Yes, 100% this. And wait when we'll release a Shufflecake-powered, fully hidden multi-OS distro ;)