From tails-dev  Sun Aug 28 08:19:49 2016
From: Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date: Sun, 28 Aug 2016 08:19:49 +0000
To: tails-dev
Subject: Re: [Tails-dev] Why Tails partition is non-deterministic?
Message-Id: <20160828081948.GA1563 () work-mutt>
X-MARC-Message: https://marc.info/?l=tails-dev&m=147237240703656
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1701169045=="


--===============1701169045==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ"
Content-Disposition: inline


--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 27, 2016 at 06:54:10PM +0000, segfault wrote:
> Hi,
>=20
> somehow I missed this thread, just noticed it right now.
>=20
> intrigeri:
> > Hi,
> >
> > thanks Joanna for raising this topic!
> >
> > I've just thought about it a little bit and I see no technical reason
> > that prevents us from resetting all timestamps in the filesystem to
> > some fixed value that depends only (if at all) on the version of Tails
> > being installed/upgraded, during some late stage of the
> > installation process.
>=20
> I think you're right. I did not test if the modification date is indeed
> the only thing that differs, but I think Joanna is right, I don't see
> anything else that should differ. This would also make tails-verifier
> less complex, because we wouldn't have to look at each file but can
> check the whole partition at once, like Joanna suggested (although the
> file verification is not the complex part).
>=20

The added value would be ensuring the unused portion of the disk blocks
(occupied by the Tails partition) are not populated with some random garbag=
e,
which might be e.g. user's previous (unencrypted) content, such as... family
pictures ;)

Generally, I think the Tails installer should at least ask the user to wipe=
 the
disk with 'dd if=3D/dev/zero'. Admittedly, because of wear leveling mechani=
sms
this might not be effective, because AFAIU modern flash memories would incl=
ude
(X*size) of the actual physical storage in order to expose (size) bytes of
storage to the host, where X > 1.=20

But perhaps if the wiping were repeated N times, where N =3D ceiling (X), w=
ith
random content this time (in order to fool any optimizations by the device),
then it should be fine?

Cheers,
joanna.

--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXwp6gAAoJEDOT2L8N3GcY3GsP/Aq2UKRRkutwwHphuihwc8bb
SdZqn7Gw2IP6pgtIU2CEmx9coQKFJUcqwozr+6wYU9gOVlYG+fXPJgPzNoSRU+BH
0EpYDwBfn9iUFb8dHNQ73LHj2jjIAhWozAxs+1YbTBhtbRBa42XYbNk8h+o+dJ5Z
IJoKduyjkVeK9T0bfeEwvPklFz85yQ+zdLWk8ssG6jW1gZTtu2WREl7YX8+dAN3S
5OjJ7cX7Lu7V6qFGAwnldqzTg3RBIpKMF75kUazpy3/91p5lQQVoMIM9+Kpv+aJT
h65YENGRgaN507aR0+zS+UttkjIkwBJG7EMZgXi2O2nPpSpMmODYzNJ4Pxn+nxZ9
4mVizKLN61LgfR1uNvdwR5SUHWSyfuHpL4xDafrhUkG5qUzjj33aWpsLryXrvI3A
y4D2CaGduaLyIatbSpBwowbBW/eoraIsED8Cy4bvVouFaFcRDDlqPpI/qO2lrQOl
5Yts7KB9UMjpxz9EWutBpgZLXNGPVe+WAdRj9IdLzub1racpVL5LsN8ARHGrHelK
v8c5+ZuEm8z0PPRVAHnCaz1ExytOBUe0HEyCbtBf/QZkbbCP1uHln3R+gvtehmWK
AT5DIGpefXcEnYiW1ov9jfsh3fUKlk7pm1uBc9p5S9CRddY5cBKNX0DlKrdk1ln+
LUqaIfMQ4vW6oXfMAFEY
=aL+Q
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--

--===============1701169045==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGFpbHMtZGV2
IG1haWxpbmcgbGlzdApUYWlscy1kZXZAYm91bS5vcmcKaHR0cHM6Ly9tYWlsbWFuLmJvdW0ub3Jn
L2xpc3RpbmZvL3RhaWxzLWRldgpUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdCwgc2VuZCBh
biBlbXB0eSBlbWFpbCB0byBUYWlscy1kZXYtdW5zdWJzY3JpYmVAYm91bS5vcmcu

--===============1701169045==--