<div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Den ons 18 aug. 2021 07:54Phillip Hallam-Baker <<a href="mailto:hallam@gmail.com">hallam@gmail.com</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Tue, Aug 17, 2021 at 10:44 PM RB <<a href="mailto:aoz.syn@gmail.com" target="_blank" rel="noreferrer">aoz.syn@gmail.com</a>> wrote:</div></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * Uses SHA-1 and MD5 digests for integrity.<br>
<br>
Both digests coupled with a known size (which most disk forensics is<br>
based on), is bad but not as wildly bad as it could be.  Moreover,<br>
they're far more interested in the physical chain-of-custody documents<br>
of a given disk and its image (usually stored offline, on another<br>
disk) than they are the cryptographic soundness of their digest<br>
algorithm. If the latter fails, guess which they trust?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">These are Merkle-Damgard constructions, so if MD5 can be broken and SHA-1 can be broken, breaking both is simply a matter of breaking them in different blocks. Easy. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Sure, the physical chain of custody is a backup. But if the defense is alleging the materials were tampered with, show the hash is broken and the case is toast.</div></div><div></div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">This was tested recently in a different way, and the conclusions which I saw from the lawyers who commented on it is that if the defense can't show the weakness were likely exposed in *their* case, then court approved chain of custody is sufficient for certifying integrity. </div><div dir="auto"><br></div><div dir="auto">See the kerfuffle caused by Moxie (one of the Signal devs) publishing exploits in a smartphone imaging tool commonly used by law enforcement. </div><div dir="auto"><br></div><div dir="auto">Original article:</div><div dir="auto"><a href="https://signal.org/blog/cellebrite-vulnerabilities/">https://signal.org/blog/cellebrite-vulnerabilities/</a></div><div dir="auto"><br></div><div dir="auto">Because after all, if courts are OK with physical evidence stored in evidence lockers where the locks can be picked, relying on outsiders not being able to reach the locker undetected, then why wouldn't they be OK with this? </div><div dir="auto"><br></div><div dir="auto">(you can make the argument that they shouldn't, and should require greater security, but this is how things works today) </div><div dir="auto"><br></div><div dir="auto">From RB:</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * No enrollment in append only log<br>
<br>
Whose append-only log do you trust, and how do you implement it<br>
isolated from Internet connectivity, which is where most actual<br>
commercial disk forensics is conducted? </blockquote></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Easy enough to solve. Generate the hashes offline, extract them (perhaps with a local offline printer), bring to them to an online system where you can publish the hashes. </div><div dir="auto"><br></div><div dir="auto">Like PHB noted, you can have multiple logs cross-reference each other to enforce "backtracking resistance". </div><div class="gmail_quote" dir="auto"></div></div>