Re: [PLUG] plug Digest, Vol 159, Issue 16

Has anyone thought about storing the data on the etherium block chain, protected by a smart contract that meets the OPs needs?

On Sat, Feb 10, 2018, 4:14 PM <plug-request@lists.phillylinux.org> wrote:

Send plug mailing list submissions to
plug@lists.phillylinux.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.netisland.net/mailman/listinfo/plug
or, via email, send a message with subject or body 'help' to
plug-request@lists.phillylinux.org

You can reach the person managing the list at
plug-owner@lists.phillylinux.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of plug digest..."

Today's Topics:

1. encrypting files with expiration (Rita)
2. Re: encrypting files with expiration (Brian Epstein)
3. Re: encrypting files with expiration (brent timothy saner)
4. Re: encrypting files with expiration (Rich Freeman)
5. Re: encrypting files with expiration (Rich Freeman)
6. Re: encrypting files with expiration (brent timothy saner)

----------------------------------------------------------------------

Message: 1
Date: Sat, 10 Feb 2018 15:24:32 -0500
From: Rita <rmorgan466@gmail.com>
To: plug@lists.phillylinux.org
Subject: [PLUG] encrypting files with expiration
Message-ID:
<CAOF-KfiYep5pgNvHX8MivzGXtJDxzf56xxmR4db6B2mdA_w6_Q@mail.gmail.com" target="_blank">CAOF-KfiYep5pgNvHX8MivzGXtJDxzf56xxmR4db6B2mdA_w6_Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

i would like to archive sensitive tax documents. i would like to store the
documents so you can't copy and paste -- just view once unlocked. set an
expiration time once unlocked. are there any tools like that?

--
--- Get your facts first, then you can distort them as you please.--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netisland.net/pipermail/plug/attachments/20180210/89eb20b0/attachment.html>

------------------------------

Message: 2
Date: Sat, 10 Feb 2018 15:33:06 -0500
From: Brian Epstein <ep@epiary.org>
To: "Philadelphia Linux User's Group Discussion List"
<plug@lists.phillylinux.org>
Subject: Re: [PLUG] encrypting files with expiration
Message-ID:
<CAG8BiWLE029rgDSi00QDGJ2FmL48+XfFbf4obcQVUntgJrzWqQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Take a look at filelocker2, I think it has a few of the features you are
looking for.

http://filelocker2.sourceforge.net/

It was developed by Perdue University. We just deployed it and are using
it for secure temporary storage and sharing.

Thanks,
ep

On Feb 10, 2018 15:24, "Rita" <rmorgan466@gmail.com> wrote:

> i would like to archive sensitive tax documents. i would like to store the
> documents so you can't copy and paste -- just view once unlocked. set an
> expiration time once unlocked. are there any tools like that?
>
>
> --
> --- Get your facts first, then you can distort them as you please.--
>
> ____________________________________________________________
> _______________
> Philadelphia Linux Users Group --
> http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/
> mailman/listinfo/plug-announce
> General Discussion -- http://lists.phillylinux.org/
> mailman/listinfo/plug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netisland.net/pipermail/plug/attachments/20180210/c729820f/attachment.html>

------------------------------

Message: 3
Date: Sat, 10 Feb 2018 15:34:18 -0500
From: brent timothy saner <brent.saner@gmail.com>
To: plug@lists.phillylinux.org
Subject: Re: [PLUG] encrypting files with expiration
Message-ID: <8ad38b44-ddb8-4cb8-afde-02baebe19c3f@gmail.com" target="_blank">8ad38b44-ddb8-4cb8-afde-02baebe19c3f@gmail.com>
Content-Type: text/plain; charset="utf-8"

On 02/10/2018 03:24 PM, Rita wrote:
> i would like to archive sensitive tax documents. i would like to store
> the documents so you can't copy and paste -- just view once unlocked.
> set an expiration time once unlocked. are there any tools like that?

this is impossible for a variety of reasons. namely:

0.) data can perform no execution on its own

1.) how would the data know when this expiration happens? how can it
trust the system computer (as the user can change this)? how can it
trust the program that handles this hypothetical data format to actually
delete it (see 0.)? how can it *not be copied* to a saved-state machine?

2.) how does it know it has only been "viewed once"? it would need this
data in a header - which are easily altered. sure, you could
sign/encrypt that header - but then you would need to include the key in
the same file, unencrypted, and we've all seen how well that works out
for... everyone that does that.

etc.

"self-destructing" data is impossible from a technological and
ideological standpoint.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.netisland.net/pipermail/plug/attachments/20180210/d8e9900b/attachment.sig>

------------------------------

Message: 4
Date: Sat, 10 Feb 2018 15:39:13 -0500
From: Rich Freeman <r-plug@thefreemanclan.net>
To: "Philadelphia Linux User's Group Discussion List"
<plug@lists.phillylinux.org>
Subject: Re: [PLUG] encrypting files with expiration
Message-ID:
<CAGfcS_kP3QzSG3F_J9EST=iQKKvo896kmaRUwsruJg8=07BTbw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On Sat, Feb 10, 2018 at 3:24 PM, Rita <rmorgan466@gmail.com> wrote:
> i would like to archive sensitive tax documents. i would like to store the
> documents so you can't copy and paste -- just view once unlocked. set an
> expiration time once unlocked. are there any tools like that?
>

Have people written software that purportedly does this stuff? Yes.

Is it relatively easy to bypass? Yes.

With hardware support you can actually get close to something like
this, assuming you want to only run it on your own hardware, and that
you don't mind the files becoming inaccessible if the hardware fails.
I don't think anybody has fully implemented anything like this in FOSS
(and perhaps not even in non-FOSS). It is theoretically possible
though.

The way you would go about it is to use hardware that includes a TPM,
with TPM support in linux (and your bootloader as well if you don't
directly boot linux from UEFI). Together these will populate the PCR
registers in the TPM during boot. Then you would run your software
and the software would request the encryption key for your file from
the TPM, and once the file is accessed the software would start the
expiration timer and enforce it. If any of the software in the chain
from firmware to your reader software (including the
bootloader+kernel) were modified in any way the TPM would refuse to
deliver the key, and the file would be unreadable. You could use a
kernel that includes special protections for the process displaying
the file so that there isn't any way to access its memory.

Again, none of this is implemented, nor would it be terribly easy to
implement. My understanding is that windows, android, and chromeos
include some of the groundwork to allow for remote attestation, though
it isn't commonly used (and the linux kernel portions are in the
vanilla kernels). Most passwordless full-disk encryption software
uses an approach like this, though they operate a bit lower-level just
to decrypt the disk and don't enforce timers/etc.

There are some vulnerabilities here:

1. If the hardware TPM is defeated your data will be compromised.
This is not easy to do.
2. If the hardware is damaged, your data will be lost. You'll need
some secure backup of your data, and this backup wouldn't have these
protections.
3. If the trusted version of any of the software
(firmware/bootloader/kernel/viewer - and any other userspace involved
like an X server/etc) contains a vulnerability, then that could be
exploitable. The scheme above ensures that none of this software is
modified, but it can't protect against vulnerabilities in the
unmodified software.

For personal use like you suggest this would be quite an undertaking.
However, it is certainly possible with the right hardware.

--
Rich

------------------------------

Message: 5
Date: Sat, 10 Feb 2018 15:45:22 -0500
From: Rich Freeman <r-plug@thefreemanclan.net>
To: "Philadelphia Linux User's Group Discussion List"
<plug@lists.phillylinux.org>
Subject: Re: [PLUG] encrypting files with expiration
Message-ID:
<CAGfcS_nb5m-483GCAA2f5Ragc24RH36-NnFVvajgG0HymOP-EQ@mail.gmail.com" target="_blank">CAGfcS_nb5m-483GCAA2f5Ragc24RH36-NnFVvajgG0HymOP-EQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

I realize you posted this before I posted my TPM solution, but I
figured I'd just comment on an element or two of this in the context
of my earlier reply.

On Sat, Feb 10, 2018 at 3:34 PM, brent timothy saner
<brent.saner@gmail.com> wrote:
>
> 0.) data can perform no execution on its own

This is absolutely true - hence the reason that I proposed a
hardware-based solution. Hardware is STILL defeatable for the reason
you bring up, though it can be very difficult to achieve. There is no
true theoretical security for something like this (which is basically
DRM).

> 1.) how would the data know when this expiration happens? how can it
> trust the system computer (as the user can change this)? how can it
> trust the program that handles this hypothetical data format to actually
> delete it (see 0.)? how can it *not be copied* to a saved-state machine?

In my solution this is achieved using a trusted viewer.

> 2.) how does it know it has only been "viewed once"? it would need this
> data in a header - which are easily altered. sure, you could
> sign/encrypt that header - but then you would need to include the key in
> the same file, unencrypted, and we've all seen how well that works out
> for... everyone that does that.

I don't think view-once was actually part of the requirements, but
again using the trusted viewer software this might be achievable.
Just store two keys in the TPM. The software requests the first key,
and stores it in RAM. Then it tells the TPM to destroy that key. Then
it requests the second key, and destroys it. Then it combines the
keys into the true key and decrypts the file. By the time the file is
readable there is no way to ever read it again.

Again, my solution only works on a specific hardware platform. (You
could of course independently set it up more than once.) There is no
way to just email a special file to somebody and have all these
restrictions enforced on their own hardware, for all the reasons
you're already getting at.

--
Rich

------------------------------

Message: 6
Date: Sat, 10 Feb 2018 16:14:05 -0500
From: brent timothy saner <brent.saner@gmail.com>
To: plug@lists.phillylinux.org
Subject: Re: [PLUG] encrypting files with expiration
Message-ID: <d8d1cffc-b520-405a-87a3-4f7f2af26488@gmail.com" target="_blank">d8d1cffc-b520-405a-87a3-4f7f2af26488@gmail.com>
Content-Type: text/plain; charset="utf-8"

On 02/10/2018 03:45 PM, Rich Freeman wrote:

> I don't think view-once was actually part of the requirements, but
> again using the trusted viewer software this might be achievable.

per OP:

"... i would like to store the documents so you can't copy and paste --
*just view once* unlocked. ..." (emphasis added)

further, a TPM cannot ensure the unlocked version of this (assuming one
did implement an encryption policy for said data using something
hardware-locked like TPM) is not copied elsewhere- not only by email,
but by other methods.

TPM does a decent job at PKI and authoring files to specific hardware.
everything else, though, and you're trying to shove a square peg in a
round hole.

in order to implement half of what you proposed, you're talking about a
significant rewrite of certain parts of the kernel - not to mention all
the other supporting userland code.

and, as acknowledged, still does not address other key parts of the
original requirements.

what OP requests is impossible, plain and simple. it'd be safer and more
practical to do it all in hardcopy, keep them in a safe deposit box, and
on a designated day fetch them, shred them, burn the confetti
(surprisingly hard to do, FYI), soak the ashes, dry them out, burn them
again.

(which is of course ridiculous for merely *tax returns*, since they're
much more susceptible/vulnerable in-transit and at destination's record
storage, but i digress.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.netisland.net/pipermail/plug/attachments/20180210/ac48117b/attachment.sig>

------------------------------

Subject: Digest Footer

_______________________________________________
plug mailing list
plug@lists.phillylinux.org
http://lists.netisland.net/mailman/listinfo/plug

------------------------------

End of plug Digest, Vol 159, Issue 16
*************************************