292
you are viewing a single comment's thread
view the rest of the comments
[-] QuarterSwede@lemmy.world 20 points 11 months ago

Yeah, it sounds good but there’s a lot of factually incorrect statements.

“Apple RCS” is actually the GSMA RCS standard, which Apple was pretty vocal about not being encrypted, but was kind of forced to use prematurely thanks to legislation. Encryption is already being looked at being added in the next spec.

How Apple encrypts iMessages is literally detailed in their support doc. In short: The per message AES key is derived from the contacts public RSA key.

The user’s outgoing message is individually encrypted for each of the receiver’s devices. The public encryption keys and signing keys of the receiving devices are retrieved from IDS. For each receiving device, the sending device generates a random 88-bit value and uses it as an HMAC-SHA256 key to construct a 40-bit value derived from the sender and receiver public key and the plaintext. The concatenation of the 88-bit and 40-bit values makes a 128-bit key, which encrypts the message with it using AES in Counter (CTR) Mode. The 40-bit value is used by the receiver side to verify the integrity of the decrypted plaintext. This per-message AES key is encrypted using RSA-OAEP to the public key of the receiving device. The combination of the encrypted message text and the encrypted message key is then hashed with SHA-1, and the hash is signed with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the sending device’s private signing key. In iOS 13 or later and iPadOS 13.1 or later, devices may use an Elliptic Curve Integrated Encryption Scheme (ECIES) encryption instead of RSA encryption.

The resulting messages, one for each receiving device, consist of the encrypted message text, the encrypted message key, and the sender’s digital signature. They are then dispatched to the APNs for delivery. Metadata, such as the timestamp and APNs routing information, isn’t encrypted. Communication with APNs is encrypted using a forward-secret TLS channel.

[-] abhibeckert@lemmy.world 5 points 11 months ago* (last edited 11 months ago)

In short: The per message AES key is derived from the contacts public RSA key.

Erm that's not how it actually works. Though in your defence, "in short" is pretty hard to achieve here.

The real headache though isn't encrypting the messages. It's making sure that only the intended recipient has the decryption key for your message. That's where E2EE messaging gets complex and frankly Apple doesn't do the best job.

It's theoretically possible with iMessage, especially in a nation state level attack, for a compromised device to be one of the recipients your encrypted message is sent to. Wether "theoretically" is "actually in practice" happening is hard to judge, because nation state attacks are normally hidden by court mandated disclosure suppression orders.

The way Signal is architected, it wouldn't be possible to comply with a court order like that. Unfortunately that means some Signal based messaging services will be forced to exit the UK since laws coming into effect next year will give them no other choice. It'll be interesting to see if signal based services (like Google RCS) also walk or will they weaken their encryption in order to be able to comply.

The fact at least one nation state is passing laws that force "encrypted" messaging services to have the vulnerability that iMessage has is a pretty strong smoke signal that attacks like that are happening....

[-] QuarterSwede@lemmy.world 2 points 11 months ago* (last edited 11 months ago)

Erm that's not how it actually works. Though in your defence, "in short" is pretty hard to achieve here. That’s why I attached the entire quote and linked to Apple’s support doc just below what I over-simplified.

But I will say the rest of what you wrote is a pretty decent insight. Thanks.

this post was submitted on 06 Dec 2023
292 points (98.0% liked)

Technology

59670 readers
1833 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS