Quote from: DarkStar_ on March 10, 2018, 07:05:43 PM

Quote from: FL4RE on March 10, 2018, 08:10:43 AM

Quote from: DarkStar_ on March 09, 2018, 08:37:50 PM

Okay, HODLER_TECH, how do you plan on sandboxing the email client, and how will the emails work in a way that prevents you from tampering with them? I don't think it would be feasible to make each device a mail server, so the address would have to be on a central mailserver controlled by you (unless you have some way around it). The emails would not be encryped, so you could easily MITM the address. Also, what prevents code execution from an email?

You got right, we will put mail deamons in our infrastrcuture, not in a wallet itself. By using 7bit ASCII only e-mails (aka plain/text) with hardcoded 255 length limit, exploiting this feature is hard, because there won't by any plugins,images etc. support, so potential attack vector should be based on MITM as you said or exploiting text but without UNICODE support is quite very hard if not impossible. The only threat i know with plain/text is EICAR Test-file, I will post it here, maybe some AV will trigger alert

Code:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

About Man in the Middle thread. Wallet cannot use standard protocols to handle e-mails like SMTP or IMAP, it won't be safe.
To prevent attack, connection between mail application in wallet and "mail server" will be encrypted in safe way, unbreakable without quantum computers.

tl;dr

>RCE prevention due to spartan protocol for emails content and app sandboxing
>MITM prevention with point-to-point safe encryption with signed data

Thanks for a good response, this explains quite a bit. What prevents you (the central server) from changing addresses before relaying the address to the wallet? Others might be unable to MITM, but you would be able to from what I gather, as well as anyone with access to your mailservers.

Just to add some additional color here (assuming we got the context correct):

- virtualization (hw-assisted software isolation) > sandboxing (pure software isolation) for the mail client

- TLS/SSL would make sure there's no MITM for data in transit, going from one place to the next

- code execution from a email is possible only if your mail client has a very serious unknown bug (possible, yet unlikely these days, especially if you're using web-based services gmail, etc), if you explicitly click through all the warnings and run some executable that bypasses any provider filters that compromises the system or you get phished and again explicitly click through 'yes im sure i want to run this malicious program' routine

- end-to-end email encryption is possible if you set it up properly, but its more efficient to just use pgp to encrypt the message in the first place so you don't have to worry if it's even intercepted or stolen on the way there, or if they get access to it later as it's currently too expensive to be successful in attacking the 2048-bit or more (today, that will change in the future though, so forward secrecy helps here); I think this is what was meant by "point-to-point safe encryption with signed data", as long as you 1) trust the signer and 2) don't lose the keys.

- sandboxing the mail server itself is an honorable mention, but just hardens things a bit and not sure if it's relevant for your threat model here

- wallet should be using TLS/SSL in every outside comm it does related to HTTPS or SMTPS/IMAPS

- AVs actually parse a ton of data and make mistakes themselves, often resulting in vulnerabilities and ironically getting users compromised. Just use VT or their APIs and if there's any bugs in the AVs, it's their problem and not yours.

- "unbreakable without quantum computers", eh if someone wants to break it bad enough, they'll hack your server and replace the software with backdoored versions, steal your keys or phish to get your credentials, etc and get around the whole encryption problem

- are you sure there's no OSS dependencies, plugins, etc adding to your attack surface? hard to know without going through the app and writing things down, version numbers, etc and making sure all libraries are up to date. also unclear how UNICODE supports helps or hurts here, but I guess it would add attack surface, yet an afterthought compared to all the other potential attack vectors.

These are the kinds of problems our team deals with to come up with solutions all the time, although most of the bugs are just avoidable coding errors which cause users to get compromised. Better to have security experts take a look if you're not confident in the security of your code.