Please Stop Writing Secure Messaging Tools (2015)
dymaxion.org
dymaxion.org
For example, (and whether you love them or hate them) Apple takes this seriously: your fingerprints don't leave the device and are implemented by a piece of hardware in such a way that even Apple doesn't have access to them. Compare that to the Android implementations which have fingerprints in the filesystem. I'm not intending to hold them up as some paragon, simply showing that securing information is more than just a messaging issue.
> your fingerprints don't leave the device and are implemented by a piece of hardware in such a way that even Apple doesn't have access to them.
This is true for Google, too.
> Compare that to the Android implementations which have fingerprints in the filesystem.
They're not stored in plaintext. They're encrypted with keys that remain in hardware. You can never read the keys, only encrypt files with them, from applications running in a separate physical address space, accessible only through the hypervisor.
This may not be as elegant as doing matching on the sensor, but keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor).
Implying that Android is somehow less secure in the case of fingerprint is disingenuous.
Security is always a risk tradeoff. My house uses special Medeco keys (modified in violation of the Medeco license as it happens) because what I want to defend against is copying when I lend out one of my numbered keys. The house is made of glass so someone could just use a brick to get in. For someone else this is a dumb tradeoff; for me it is appropriate.
And your message includes an example of such a tradeoff:
>This may not be as elegant as doing matching on the sensor, but keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor).
>Somehow implying that Android is less somehow less secure in the case of fingerprint is disingenuous.
The channel between the two separate devices is an attack surface (as is the opportunity for offline attack on the encrypted data in the filesystem). The Android team has made the determination that that's an acceptable risk. I won't argue -- perhaps I agree and perhaps I don't, but it is unambiguously less secure than the single, all-encompassing approach. To claim so is hardly disingenuous.
Of course, as with my house, this just changes the class of attack. On either platforms you can consider attacking whatever authentication module talks to the TEE. Both systems use other mechanisms for that.
Finally, in the Android case a vendor is free to do what they want, especially if they don't care about access to branding, google services etc. Google branded devices have a more important brand to defend than, say, Asus (not to pick on Asus), much less, say, DJI's drones, for which the Android branding is utterly irrelevant (conceivably that could rebound on Google though personally I doubt it would even happen. The same obviously can't be said about iOS :-)
FWIW, "disingenuous" carries the connotation of intentional deception, i. e. making an argument in bad faith, because one knows that it's wrong.
In this case, I can understand where the defence of Android's implementation is coming from: the original description amounted to "plain text in the filesystem, but the name ends in .mp3 so nobody will find it", whereas the reality seems to be a slightly less elegant solution that can probably be subverted by a dedicated nation-state, but is unlikely to ever make a difference in most people's lives.
I would like to hear more about these modifications.
That key system also lets you do the usual key control designing, like a master key that opens everything, and a loaner key that only opens the front door, for example. Like any security system, you will want defense in depth, and have other layers protecting other aspects.
By 'in hardware', I'm guessing you don't mean real silicon / flash, but rather whatever persistent storage is provided by the SoC vendor's TrustZone implementation. In my opinion calling that 'hardware' implies a level of security and verification that is not actually present, and is disingenuous.
If history has shown us anything, it's that relying on a chipmaker's security assurances for platform software features can only end in tears. You don't need to look very far to find real world examples of exploits against TZ stacks [1].
[1] https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Att...
Why is that?
Trying to use it for general encryption might have problems and is more often discussed than done.
SIMs are basically just javacards, so having custom crypto applications on them is no big deal, but you need some control of the SIMs your users will want to use in your device for it to be practical.
* I.e. there are a lot of issues for Google generalizing encryption via some user provided sim as datails come up. So maybe he is referring to an entirely different crypto module.
(Android Fingerprint HAL document: https://source.android.com/security/authentication/fingerpri... )
(Note that the document allows storing fingerprints on FS, but they must be additionally encrypted. Better devices do not do that.)
The need for a trusted path has been well understood since the 1960s at least (and its roots run back through the "break" key on the teletype); it's reflected in the rainbow books and of course in the design of Multics. Plenty of people at Google understand this well; some of them even participated in writing those rainbow books!
You can ship a device without passing CTS and it is very common (though TBF, things like my Mavic drone don't have a thumbprint sensor).
And just a few months ago, HTC shipped a phone with unencrypted fingerprints: https://www.theguardian.com/technology/2015/aug/10/htc-finge...
Again, I'm not holding Apple up as some paragon, it was simply the example I used to point out the importance of security design at depth, defense at depth, and integration into all aspects of a system.
https://betanews.com/2015/08/11/htc-and-samsung-phones-stori...
Best security is passprase with a TPM chip.
Depends on your adversaries, of course. I fear that if police might want to open my phone, they'll beat me until I'll unlock it and whether it's a passphrase or fingerprint — it doesn't matter.
It is okay to use fingerprint to open the screen. But there should be shut-down finger.
Not to mention your fingerprints are all over the device!
Anyone who takes security seriously should open-source the security aspects of the system. Putting them in a proprietary black box is one the worst ways to guarantee security.
Also, fingerprints or few-digit pins should be only used as casual deterrents to people grabbing and doing something with your phone before you can get to it. Those should not be used to encrypt sensitive data. Good security comes from good, high-entropy passwords.
The iOS 11 version and detailed FaceID details should be coming out soon as well.
A special place in hell should also be reserved for those in the tech world that mix up security (a real and critical need that people have) and their software politics. If you don't like Microsoft, Google, Adobe, "the Cloud", or smart phones, that's fine. There are plenty of reasons. But don't short circuit security assessments in the interest of promoting technology you find politically superior.
Document-sharing with edits being tracked is the big one, though (like the article raised).
Also, Signal being tied to a phone number is a nightmare.
I disagree. Sitting on a phone and sweet-talking sources isn't high-tech, and neither is bundling up five tweets to make a clickbait.
But as soon as you're talking about doing public records research, tracking the activities and ownership of a multi-national company, working in a team with people from 30 countries on a single story, try to manage your confidential evidence across five years, it becomes quite technical.
Calendaring system: Google Calendar, iCal
Contacts databases: GMail Contacts, Apple Contacts
Location coordination tools: Google Latitude, Find My Friends.
Some of those programs don't exist, as far as I'm aware. A Wiki/Etherpad/Word style change tracking mashup, and Map-based storytelling and analysis systems are two that I'd like to see implemented.
https://webcache.googleusercontent.com/search?q=cache:pwT4ik...
Restarting the Riot had helped me to see the new messages, but not the old ones (which feels to be a correct behavior in regards to PFS). The actual problem is other party didn't knew I had issues receiving their messages until I've contacted them out-of-band - conversation looked just normal from the other side (except for me writing "test test" and not replying any meaningfully).
We ended up with a decision to try Matrix again sometimes later. Like, next year.
This is very relevant because decentralized means that all that centralized storage and bandwidth needs to split up and amplified to account for offline users.
Yes, but secure messaging is a well understood domain I suppose so it's the kind of app that is simple(not easy) to write and most tools compete on UX. A lot of tools on the list at the end have complex domains that are not that well understood by stock developers, or they might require a lot of R&D or actually talking to teams that have a problem to solve.
Furthermore it is extremely difficult to market a lot of these tools to corporations. IM? it's fairly easy.
The situation with secure messaging apps today isn't so different than social networks in the 2000's. It's a formula and it's easier to raise capital on that formula at the moment.
Some examples I know I've used: PMS, Wiki, Calendar, VFM. I'd love a good group password vault, so far I've come up empty for something open source...
self-hosted / free / open-source password vault. extensions for every major browser out there (edge / ff 57)
Can't really say that if the stock browser on macOS isn't supported...
[0]: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
[1]: https://security.googleblog.com/2017/01/security-through-tra...
https://web.archive.org/web/20171015070908/https://dymaxion....