[HN Gopher] Should We Chat, Too? Security Analysis of WeChat's M...
___________________________________________________________________
Should We Chat, Too? Security Analysis of WeChat's Mmtls Encryption
Protocol
Author : lladnar
Score : 74 points
Date : 2024-10-16 20:06 UTC (2 hours ago)
(HTM) web link (citizenlab.ca)
(TXT) w3m dump (citizenlab.ca)
| kccqzy wrote:
| I personally am not very interested in this research. WeChat is
| well known not to use end-to-end encryption. Considering that the
| app is unlikely to adopt end-to-end encryption (likely due to
| censorship being a business requirement, which was mentioned in
| the article and previously uncovered by this lab), I don't really
| feel like I care a whole lot between good non-end-to-end
| encryption and bad non-end-to-end encryption. Parties that are
| interested in subverting this kind of encryption, such as
| governments, likely already collaborate Tencent to get decrypted
| messages from the source.
| palata wrote:
| > I don't really feel like I care a whole lot between good non-
| end-to-end encryption and bad non-end-to-end encryption.
|
| That's the difference between "you have to trust WeChat" and
| "anyone can read your chats". Of course you may not personally
| be interested because you don't personally use WeChat, but for
| the billion active users who do, I think it should matter.
| kccqzy wrote:
| Where did you see that "anyone can read your chats" in this
| article? Indeed near the beginning of the article in the
| fourth bullet point the author states "we were unable to
| develop an attack to completely defeat WeChat's encryption"
| right there. The only parties who are interested in expending
| more effort to break this kind of encryption are just
| governments, who can simply force Tencent to give up
| plaintext records.
| kadoban wrote:
| > I don't really feel like I care a whole lot between good
| non-end-to-end encryption and bad non-end-to-end encryption
|
| Bad non-end-to-end encryption is exactly that: "anyone can
| read your chats". That's not what the research found, it's
| just the implication of your original statement.
| datadeft wrote:
| Yep. Btw the threat model for me is this:
|
| - against random 3rd party, even WeChat is ok
|
| - against random black hats, most of chat software is ok,
| maybe even WeChat
|
| - against gov agencies, nothing is going to protect you
|
| When I am in China, i happily use WeChat including the
| gazillion of services available through it. Buying metro
| pass, ordering food, getting a battery pack and so on.
|
| Btw no country could replicate this outside of China, which
| is an interesting phenomenon. We have endless ads including
| actual scams and malware distributed by Google Ads yet I
| cannot buy train tickets in the EU through a single app and
| order food as well, let alone getting a cab. It would be
| great though.
| palata wrote:
| > Where did you see that "anyone can read your chats" in
| this article?
|
| I didn't. I answered to what you wrote, which I quoted. But
| I can quote it again:
|
| > I don't really feel like I care a whole lot between good
| non-end-to-end encryption and bad non-end-to-end
| encryption.
| mouse_ wrote:
| Show me the outcome and I'll show you the incentive.
|
| Hint: backdoors
|
| I wouldn't trust any federally approved encryption. From any
| country.
|
| I wouldn't trust them, but I WOULD use them, given no other
| choice to reach the users I'm after. But always assume zero
| trust. With any computer thing, zero trust. Computer systems and
| those who orchestrate them are sneaky little devils.
| creatonez wrote:
| And even if it isn't screwed up by active malice... don't be
| surprised if it's screwed up by pure incompetence. South
| Korea's internet is still plagued by government-approved
| encryption standards, which, due to the deprecation of ActiveX,
| sometimes require installing institution-specific cryptography
| software to tunnel connections through a local HTTP server so
| it can be encrypted outside of the web browser -
| https://palant.info/2023/01/02/south-koreas-online-security-...
| palata wrote:
| > I wouldn't trust them, but I WOULD use them, given no other
| choice to reach the users I'm after.
|
| Which is no different from trusting them. The reality is that
| you have to trust something at some point.
| dtquad wrote:
| The Chinese government has direct access to the WeChat backend so
| it's unlikely that these weaknesses were government mandated.
| Probably just the result of overworked 996 developers:
|
| >The name 996.ICU refers to "Work by '996', sick in ICU", an
| ironic saying among Chinese developers, which means that by
| following the "996" work schedule, you are risking yourself
| getting into the ICU (Intensive Care Unit)
|
| https://github.com/996icu/996.ICU
| daghamm wrote:
| WeChat is basically one of the tools the communist party uses
| to control the population. If something is on there it is most
| likely by design.
|
| Off topic (or is it?): While back a western journalist in China
| reported that her wechat account was banned 10 minutes after
| changing her password to "fuckCCP"...
| tptacek wrote:
| The point being made in the preceding comment is that the
| threat model for WeChat already overtly includes its
| operators being able to puncture its confidentiality. It
| doesn't make a lot of operational sense to introduce
| complicated cryptographic backdoors (such as the IV
| construction, which the authors say could potentially
| introduce an AES-GCM key/IV brute forcing attack) when you
| control the keys for all the connections in the first place.
| throwaway48476 wrote:
| Not only control keys, but control the software update
| mechanism (backdoor a la xz).
| homebrewer wrote:
| I had my account banned for absolutely no reason (I didn't
| even use it to talk to anyone and was simply learning the
| interface myself to explain it later to a friend who was
| traveling to China). You can't infer anything from that
| story. Their "security" automation is even more paranoid than
| Google's, that's probably all there's to it.
| bzmrgonz wrote:
| What do you say to observers who would see this analysis as a
| parallel to the huawei or Tiktok western argument, meaning,
| "don't let them spy on you, let us spy on you instead!!!"
| two-sandwich wrote:
| Is there something you'd like those observers to hear?
| jeltz wrote:
| Isn't this the opposite? It is warning that WeChat's security
| might be weak since it is using weird non-standard stuff which
| means everyone might be able to spy on WeChat users, not just
| China. If WeChat fixed this then only China would be able to
| spy on the users.
| thimabi wrote:
| WeChat using a custom protocol like MMTLS instead of sticking
| with something solid like TLS 1.3 is a risky move. Rolling your
| own crypto almost always leads to trouble. Of course, there may
| be ulterior motives behind Tencent's decision, and users have
| little power to change it. For an app with over a billion users,
| that's pretty concerning.
| spacebanana7 wrote:
| I wonder whether WeChat is one of the safest messaging apps
| because it has the strength to say no to western agencies.
|
| Signal and Matrix can be pressured with a rubber hose if there's
| enough desire. And I imagine bureaucratic equivalents exits for
| iMessage and WhatsApp. But the CCP can offer genuine protection
| to WeChat executives.
| osamagirl69 wrote:
| I have not been following the end-to-end encryption discussion
| in a while so please excuse my ignorance in asking...
|
| How does the 'rubber hose' threat apply to Matrix? So long as
| you are in control of your home server (or at least use a home
| server you trust) I am not sure who your advisary would
| pressure.
| jeltz wrote:
| They could force them to add a backdoor in the Element build
| uploaded to the app store so they can use that backdoor to
| attack specific users. This is why we need reproducible
| builds and code which automatically check for discrepancies.
| palata wrote:
| > I wonder whether WeChat is one of the safest messaging apps
| because it has the strength to say no to western agencies.
|
| That is not how cryptography works.
|
| If you use proper end-to-end encryption (e.g. the Signal
| protocol), and assuming that you use it properly, then the
| server does not have access to the content of the encrypted
| messages. So the server cannot be pressured, period. So the
| Signal protocol is strictly better than a protocol that is
| audited and found wanting (TFA talking about the WeChat
| protocol here).
| vbezhenar wrote:
| Until next update will send your keys. Do you disassemble
| every update? I doubt it. In the end it's all about developer
| trust, because no popular messaging has thriving multi-client
| ecosystem after Jabber was abandoned. They all have
| "official" blessed client and some even fight third-party
| clients.
|
| Not even talking about server side, things are just grim
| there.
| upofadown wrote:
| >Generally, NIST recommends[1] not using a wholly deterministic
| derivation for IVs in AES-GCM since it is easy to accidentally
| re-use IVs.
|
| A quick skim of the referenced document did not show where NIST
| recommended against the use of deterministic IVs. The document
| actually spends a significant amount of text in discussing how
| one would do such a thing. Did I miss something?
|
| >Lack of forward secrecy
|
| The article mentions that the key is forgotten when you close the
| app. Probably enough forward secrecy for most people.
|
| >Since AES-CBC is used alongside PKCS7 padding, it is possible
| that the use of this encryption on its own would be susceptible
| to an AES-CBC padding oracle, which can lead to recovery of the
| encrypted plaintext.
|
| This is a messaging app. Is there actually an available oracle?
| Does the implementation even generate a padding error?
|
| [1]
| https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...
| maxglute wrote:
| Whatever technical merit, Three Open Technology Fund fellows,
| funded by United States Agency for Global Media (read US
| propaganda wing), more specifically fellows of Information
| Control Fellowship program, recommending wechat to adopt western
| encryption is top kek. More and more OTF/ICFP funded studies
| (that coincidentally targets US adversaries) getting laundered
| through uoft/citizenlab every year.
| throwaway48476 wrote:
| By "western encryption" do you mean crypto systems that have
| been subjected to public scrutiny?
| maxglute wrote:
| Systems whose scrutiny/reputation is more subject to western
| "trust me bro". Authors had courtesy to recognize TLS drama
| in 2010s, and assumes it's... better/sufficient now because
| why, a bunch of US companies, many with teams of ex US
| intelligence on internal security teams is doing bulk of the
| scrutinizing.
|
| PRC seems to like their home-grown cryptography gated behind
| language barrier. Maybe they're hedging on bet that enough
| diverse implementations better than eggs in single basket. Or
| the amount of Chinese fluency decreasing in west going to add
| another layer of security/obscurity. Ultimately who knows,
| other than PRC would be idiotic to listen to OTF-ICFP funded
| recommendations, a program that avoids "focus" on countries
| with minimal information controls, i.e. if there's a reason
| not to trust western scrutinized crypto systems, you likely
| won't find it from OTF and citizenlab.
| throwaway48476 wrote:
| I don't see how the language barrier provides any security.
| If your threat model is foreign governments and you're
| rolling your own crypto you have to assume they have plenty
| of budget for translation. Technology is one of the main
| collection activities of any spy agency.
|
| Trust in a crypto system is established by having multiple
| adversarial parties use it and the system being open to
| attack for many years without success.
| imiric wrote:
| These findings are so unsurprising that the research is
| borderline boring.
|
| What I would like to see are similar efforts directed at the
| tower of complexity that is the modern TLS stack. From the
| Snowden leaks we know that the NSA has tried to break
| cryptographic algorithms for decades via their project Bullrun,
| and that they bribed the RSA to default to their compromised
| algorithm. From the recent XZ incident we also know that supply
| chain attacks can be very sophisticated and difficult to detect.
|
| How likely is it that the protocols we consider secure today are
| silently compromised by an undetected agent? Should we just
| assume that they are, like a sibling comment suggested?
|
| I'm frankly more interested in knowing if there is oversight of
| these complex technologies that could possibly alert us of any
| anomalies of this type, so that we don't have to rely on
| whistleblowers or people who happen to notice strange behavior
| and decide to look into it out of curiosity. Too much is at stake
| for this to be left up to chance.
___________________________________________________________________
(page generated 2024-10-16 23:00 UTC)