External encrypting proxy w/ Qubes?

[Oleg Artemiev]

Mailed this to qubes users, but didn't get any comments yet.

Is the idea of having an external computer with key/encryption
operations like a special proxy is interesting from your point of
view?

Main question - is it possible anyway to have no need in trust to OS vendor?
My point is that this is possible only when vendor provided OS
operates only with already encrypted data.

Details below:

------------------------------------------cut--------------------------------------------------------------
I've found recently discussion on a forum on trusts for javascript
code that is loaded from network and pretends to realize easy to use
encryption of mail.

Agreed that here you have to trust vendor of the code ultimately.

Question I keep since I'm using Qubes - is it possible anyway to have
no need in trust to vendor?

Intro, required to understand context:

Those old times when irc was the primary channel in our communication
within a team of a few geeks interested also in security one of us
made an encrypting proxy with dynamic key exchange.

From outside this looks like this:
1) there is an irc channel - a known place to meet and talk w/o encryption
2) once two people need to use secure communication they agree on
this (usually opening then a private 2 person chat in separate window).
Each of two clicks a button <enter encrypted mode>. The software uses
an encrypting proxy model and takes dynamic key create/exchange +
encryption/decryption phase by encrypting/decrypting talk on the fly.

The conversation if used on the public channel looks like a dump of
ascii armored encrypted file - just a flow of strings that a 3d party
cannot easily decrypt.

So it was a proxy for encryption and dynamic key exchange.

The basic idea is that only proxy has a clue about encryption and key
exchange.The client uses simple text protocol and all encryption is
seamless - you don't have to change the software itself.

Well, what if we try similar idea when organising secure
communications using 2 computers and diffrent VMS with two Qubes PCs?

The requirement is to have at least one VM in Qubes installed as
usually that never operates w/ unencrypted data after entering
"transparent encryption of data". Is it possible at all?

The main problem is that when we want to make seamless encryption via
proxy the protocol has to be easy separated to data and control
sequences.

I.e. we can connect as keyboard "a resulting flow of encryption made
in other VM", but the software running inside such a VM will interpret
some of that input as a control sequence and, for example, react to
data like on a special key press. If I get as a proxy into another VM
- I've to read and answer on that VM also.

Any comments?
------------------------------------------cut--------------------------------------------------------------

--
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

[Matteo]

> Is the idea of having an external computer with key/encryption
> operations like a special proxy is interesting from your point of
> view?

> Main question - is it possible anyway to have no need in trust to OS vendor?

i think no, at some point you have to trust someone.

> I've found recently discussion on a forum on trusts for javascript
> code that is loaded from network and pretends to realize easy to use
> encryption of mail.

this is no different from gpg, you trust it or you don't.
the difference is that when you have downloaded gpg it doesn't change
over the time and it can't (if we exclude virus) while javascript based
encryption is downloaded everytime from the network so it can be changed
and unless you somehow compare it for changes you don't know if it has
been subverted.

> The basic idea is that only proxy has a clue about encryption and key
> exchange.The client uses simple text protocol and all encryption is
> seamless - you don't have to change the software itself.

rootkovska proposed something "similar":
-hardware based encryption of hhd so a virus can't hide something on the
hdd to be recovered later because it will be encrypted (but not the
current one because is s**t)
-hardware enforced tor, so if a virus leak data (password for example)
on internet noone can understand who is the owner of that password

for a more detailed, correct and complete presentation check this
pdf+video, they are really intresting:
https://blog.invisiblethings.org/papers/2015/state_harmful.pdf
https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Besides the above, one more comment:

On Sat, Feb 04, 2017 at 11:33:26PM +0300, Oleg Artemiev wrote:
> The main problem is that when we want to make seamless encryption via
> proxy the protocol has to be easy separated to data and control
> sequences.

The proxy needs to be protocol-aware, which doesn't scale well. And
additionally, for that proxy to work, the application needs to use
not encrypted connection - so not even SSL/TLS. This is (fortunately)
rarer and rarer nowadays.

As the work needs to be done for each protocol separately, it's easier
to add encryption support to particular application, instead of using
additional proxy. And indeed there are such plugins for multiple
applications, like Enigmail for Thunderbird, OTR plugin to various XMPP
clients etc.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYl7ncAAoJENuP0xzK19csrgIIAJEsqxemQcuJtT9oCLI7mA+c
F2XBOTjmRkpM1xhhCfS38v3ZO1h2XT5R081AfHrLV/GCbLFW6QEJeK5kI01JtbD0
lMw5Eec1ZsyEhOeVn9P8OBR83a1k353Y8SVX08ZS8uJTosWN9fr7+yAFaUXNtcyY
sNtA3NdfSDF5eMXbWlG/gQuqmsehpr3x8fR7jo2DrZhJyrhDkj87BEsPUBA2PTYu
vvDqXd/45vwoPcFkuA1USXBE3MC0tp139tAOwkcXKHkc9VUFOGwUxcTSdUKaGguu
yWEcOpO4oDOQxJke22U458nUQnorHbu9VlgT8ZIbqMB33Ic4lTTxkMw0i+1HAEI=
=Wy4s
-----END PGP SIGNATURE-----

[Oleg Artemiev]

On Mon, Feb 6, 2017 at 2:48 AM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sun, Feb 05, 2017 at 04:48:46PM +0100, Matteo wrote:
>>
>> > Is the idea of having an external computer with key/encryption
>> > operations like a special proxy is interesting from your point of
>> > view?
>>
>> > Main question - is it possible anyway to have no need in trust to OS vendor?
>>
>> i think no, at some point you have to trust someone.

when I've two PCs w/ Qubes one of which is not connected anywhere,
only to 1st PC - it is possible to
make a configuration when 1st PC gets for some AppVM only encrypted
traffic from some moment.

Thus all data passed into such an AppVM is either not important either
already encripted, but could be
operated w/ usual software when switch back to non-proxy mode (i.e.
w/ file manager you may operate w/ files, show preview to see that
content
is just armored pgp like unreadable stuff, send to someone via usual mail).

>> > I've found recently discussion on a forum on trusts for javascript
>> > code that is loaded from network and pretends to realize easy to use
>> > encryption of mail.
>> this is no different from gpg, you trust it or you don't.

I trust encryption them realized and world wide well known security
practice them got.

>> the difference is that when you have downloaded gpg it doesn't change
>> over the time and it can't (if we exclude virus) while javascript based
>> encryption is downloaded everytime from the network so it can be changed
>> and unless you somehow compare it for changes you don't know if it has
>> been subverted.

when code is complex and is at least once downloaded in binary, not
built from trusted signed sources there're
anyway still low chances to get powned.

Qubes lowers these chances much more then any other OS. Though I've to
trust vendor and their binary distribution system.
And I do - it's okay when I've no more to hide then everyone around.

If external proxy is realized as a separate computer that is not
connected to the network but only to the main-work Qubes OS,
then scheme with one or more AppVMs that never receives non-encrypted
data since entered "super-paranoid-mode"
could be easilly realised. Thus for data entering such an appVM I can
have no trusts at all (but still trust to encryption
algo) including vendor trusts. The second "encipting proxy" doesn't
require to be a Qubes box.

>> > The basic idea is that only proxy has a clue about encryption and key
>> > exchange.The client uses simple text protocol and all encryption is
>> > seamless - you don't have to change the software itself.
>> rootkovska proposed something "similar":
>> -hardware based encryption of hhd so a virus can't hide something on the
>> hdd to be recovered later because it will be encrypted (but not the
>> current one because is s**t)
>> -hardware enforced tor, so if a virus leak data (password for example)
>> on internet noone can understand who is the owner of that password
>>
>> for a more detailed, correct and complete presentation check this
>> pdf+video, they are really intresting:
>> https://blog.invisiblethings.org/papers/2015/state_harmful.pdf
>> https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops

Thank you, will look. :)

> Besides the above, one more comment:
> On Sat, Feb 04, 2017 at 11:33:26PM +0300, Oleg Artemiev wrote:
>> The main problem is that when we want to make seamless encryption via
>> proxy the protocol has to be easy separated to data and control
>> sequences.
> The proxy needs to be protocol-aware, which doesn't scale well.

+1

> And
> additionally, for that proxy to work, the application needs to use
> not encrypted connection - so not even SSL/TLS.

This is not generally a problem:

realize a simple text protocol that such a proxy and keyboard driver
understands.
once a protocol requests super secure mode:
1. the proxy starts its work,
2. the keyboard driver is detached from AppVM to work in
proxying-encryption mode
and receive input not from user keybpard but from remote
encrypting proxy (that is
network and phisicaly separated)
4. any other software works as usual.

Steps below are optional, but may make all look better

5. super secure App VM opens text mode window or better switched to
text mode fully
6 the video driver in super secure AppVM is requested to send via
netwrok the video memory to encrypting proxy
(text only from textmode video memory needs to be processed,that's why
text mode window. To process grafical
output ).

Finally

7. unencrypted input and output is available only in encrypting proxy.
8. user on the fly looks that data passed in encrypting proxy appears
in "super secure" App VM as encrypted.
9. connection between encrypting proxy and "super secure" AppVM is
9.1 network separated.
9.2 physically separated (only fisical location of display and
keyboard in reall world must match for both computers).
9.3 User can control "super secure" AppVM via mouse controls. This
is oftenly enough to send mail, operate w/ GUI
software w/ files and editor & so on.
9.4 the data required to be processed w/ extra security never
enters operating/storage VM in unencrypted mode
9.5 the data sent to super secure VM never stored on encrypting
proxy computer.

Once you have a protocol for this - it could be passed out via network
anywhere via any tunnel, including ssl/tls.

To test realisation of such a thing we 've no need to have second
computer even - possible to emulate within single Qubes PC.

> This is (fortunately)
> rarer and rarer nowadays.

The software to be used between secure proxy and AppVM:
*. allow to switch modes - proxy/non-proxy
You 've no need to even pass a "switch to proxy model" on protocol
level - this could be done via menu in "super secure" AppVM.
*. block keyboard input
*. emulate keyboard driver to process data passed from encrypting
proxy like it comes from keyboard.
*. pass video memory to encrypting proxy as is (or better only text
part from video memory)
*. decrypt fixed size blocks (80x25 or other standard text mode) +
display on PC3 directly to same text mode video memory .
*. encrypt user input and pass to AppVM .

> As the work needs to be done for each protocol separately, it's easier
> to add encryption support to particular application, instead of using
> additional proxy.

The reason for protocol above is make an option to drop vendor trusts
to as minimum as possible.

When separation is done that way:
*) stealing data from "super secure" AppVM has no sense (till
encryption is okay).
*) Attacks between PC1 and PC2 could be filtered as usually Qubes does.
*) Initiatation of such attack from vendor side it harder then ether -
imagine that vendor is forced to get the
data entered in proxy VM.
The 1st thing to do then is send targeted update, better individual.
Let's imagine vendor side found how to send such an individual
update to PC1 dom0 or "super secure" AppVM and user has installed it a
few months later.

But what next - PC2 is not connected to the internet - only to
PC2,never updated, uses Qubes security model of separation.

Data passed from PC1 to PC2 never user operated - direct copy to
video memory. No usual shit like lure user and he/she will run code
for us.
Data from keyboard is one way - PC2->PC1 , never back via that
channel - sending module on PC2 is not exploitable (at least if made
to send and never confirm) .
Any operations for powning PC1 are irrelevant - all you can do is
get already encrypted data.

Getting from PC1 into PC2 becomes not that easy when you have no
way to send an active content (every block after decryption is gooing
directly to video
memory and is operated by usual video card hardware - any overflow
within a block will just get rubbish on screen and never code
execution ) . Each block
is fixed size - easier to operate on it securely.

> And indeed there are such plugins for multiple
> applications, like Enigmail for Thunderbird, OTR plugin to various XMPP
> clients etc.

All of these require to be executed in trusted operating system.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Feb 06, 2017 at 10:53:14PM +0300, Oleg Artemiev wrote:
> > And
> > additionally, for that proxy to work, the application needs to use
> > not encrypted connection - so not even SSL/TLS.
>
> This is not generally a problem:
>
> realize a simple text protocol that such a proxy and keyboard driver
> understands.
> once a protocol requests super secure mode:
> 1. the proxy starts its work,
> 2. the keyboard driver is detached from AppVM to work in
> proxying-encryption mode
> and receive input not from user keybpard but from remote
> encrypting proxy (that is
> network and phisicaly separated)
> 4. any other software works as usual.

This reminds me this talk:
https://fahrplan.events.ccc.de/congress/2016/Fahrplan/events/8014.html
https://media.ccc.de/v/33c3-8014-untrusting_the_cpu

I really recommend watching it.

(...)

> > And indeed there are such plugins for multiple
> > applications, like Enigmail for Thunderbird, OTR plugin to various XMPP
> > clients etc.
> All of these require to be executed in trusted operating system.

That's true. Even if we use thing like split-gpg, we still depend on
that application to actually use that tool.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYmNt7AAoJENuP0xzK19csK70IAI2vL/NGnAPLHYOSWmlyytrs
laYAOgbNZAKv4vMUWPzG8EmYab9PGXM46PVfLG9kQhq14Uw2gv278JLICPuZDB70
DtpKHA0hjB9eJfW5hYO6orzlYuCa30eEpfFlhq/XkzuEeFezs6SzaQD65cdIXQya
ayxlGs/DpoEkiU0pIMArvwHaJkkn4Kt1eaLD78TYVRuIrnYnCpN/6NMRTV7dTO/r
vIbj+rBvqIgOJQF0Axc/5s9V6dLGeDQq3KnUb18Y0IYV8l+cNAmhqLcTOWiHUPQa
byVnPE3y6/QRQ341szaQp9nkVYq5SXh/McmaPeBr1XGjR0ht3ZdBaklq754wp58=
=eiMj
-----END PGP SIGNATURE-----

[Oleg Artemiev]

On Mon, Feb 6, 2017 at 10:53 PM, Oleg Artemiev <grey...@gmail.com> wrote:
[..]

>>> > Is the idea of having an external computer with key/encryption
>>> > operations like a special proxy is interesting from your point of
>>> > view?
>>> > Main question - is it possible anyway to have no need in trust to OS vendor?
>>> i think no, at some point you have to trust someone.

[..]

> when code is complex and is at least once downloaded in binary, not
> built from trusted signed sources there're
> anyway still low chances to get powned.
> Qubes lowers these chances much more then any other OS. Though I've to
> trust vendor and their binary distribution system.
> And I do - it's okay when I've no more to hide then everyone around.

[..]

> If external proxy is realized as a separate computer

[..]

> then scheme with one or more AppVMs that never receives non-encrypted
> data since entered "super-paranoid-mode" could be

[..]

> Thus for data entering such an appVM I can
> have no trusts at all (but still trust to encryption
> algo)

[..]

>>> pdf+video, they are really intresting:
>>> https://blog.invisiblethings.org/papers/2015/state_harmful.pdf
>>> https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops
> Thank you, will look. :)

Haven't read the paper yet, but just watched video w/ Joanna talk w/
idea explanations.
Perfect. :)

> realize a simple text protocol that such a proxy

[..]

> 2. the keyboard driver is detached from AppVM to work in
> proxying-encryption mode and receive input not from user keybpard but from remote
> encrypting proxy

[..]

> 4. any other software works as usual.

[inserting from another message:]

>> This reminds me this talk:
>> https://fahrplan.events.ccc.de/congress/2016/Fahrplan/events/8014.html
>> https://media.ccc.de/v/33c3-8014-untrusting_the_cpu
>> I really recommend watching it.

>Thanks. Enjoyed,Interesting. Makes 2nd PC unneeded and about
> the same thing (almost).
>Though it is a proof of concept and needs a lot of things to be
>implemented - far from realizing this and it looks harder, then
>implement similar thing via usual software with two computers.
But:

>And this is a problem to intercept usual laptop w/ this.
> My idea simpler to realise,
Will work with any two PCs (qubes + qubes or qubes + any other os)

--