I understand that in order to have PFS you must use different keys to
encrypt messages. So your IM client could be generating a new key for
every message you write (or every few messages).
This would mean that DH exchange will happen to generate a new key and
then both IM clients should have that key so the sender can encrypt
the message with it and the receiver can decrypt it.
Did I understood it right so far ?
Not quite.
PFS is the property that plaintext confidentiality for passively captured ciphertexts is retained even if a long-term key is compromised.
As an example of a system without PFS, in traditional SSL/TLS configurations one might use the long-term RSA keypair (from the certificate) as a way to exchange a session key. This is called static key exchange. The problem is that if an attacker records all sessions and compromises the certificate at a later date, they may decrypt those sessions using the RSA key. This is, understandably, a problem.
TLS uses Diffie-Hellman (DH) in an ephemeral manner, known as DHE. Ephemeral, in this case, means that the keys or parameters used to exchange the key are discarded after the session is created.
Diffie-Hellman has the property that two parties can agree upon a shared secret in a context where an attacker is watching, without exposing that secret to an attacker. An incredibly simplified (mathematically incorrect, but more intuitive) description of DH would be that Alice generates a pair of values As and Ap (secret and public) and Bob generates a pair of values Bs and Bp (again, secret and public), each with certain special mathematical properties. By exchanging Ap and Bp, both Alice and Bob can calculate the same resulting secret value x. If Eve, an eavesdropper, listens in on the exchange of these values (i.e. she knows both Ap and Bp), she cannot calculate x because she does not know As and Bs (i.e. the secret parts).
As a short aside, DH on its own has a problem: an active attacker can man-in-the-middle the DH exchange and interpose their own secret values in order to compromise the connection. DH alone has no resistance to active tampering, and we generally call this kind of usage "anonymous DH" or ADH. In TLS we solve this by signing the exchanged DH values with the long-term RSA key in order to prove that they have not been modified.
Diffie-Hellman Ephemeral (DHE) works by randomly generating the DH secrets for each session, exchanging the public parts, then throwing those secrets away after x is calculated. You'll notice in the exchange between Alice and Bob above that the As and Bs parts are never transmitted, and that Eve cannot calculate x without them. Once As and Bs are discarded, nobody can recreate x. If you compromise the long-term RSA key, you cannot recover plaintexts from previously recorded sessions and ciphertexts.
But then I see that some IM clients allow using multiple devices to
access encrypted messages.
Does this mean that the private key and the encryption keys would need
to be copied to every device ? Is not this a security risk ?
Is there any protocol or cryptographic method to copy this private key and encryption keys securely to other devices ?
Multi-party encryption is complicated and there are a bunch of different mechanisms that are involved. I personally think that Signal's double ratchet algorithm is one of the most easily understood and elegant solutions to the problem, but even that is a fairly involved system. I recommend that you read the paper as it is very well written with minimal crypto jargon.
The way these protocols generally work is that you have some sort of long-term identity key that gets exchanged between devices in some way (e.g. via QR code) when you pair them to your account. This key gives you different levels of access depending on the protocol - in the case of Signal and WhatsApp it allows that device to "join" a group chat in your name. When any party in the group sends a message, it encrypts it for each of the other parties (including each individual party sharing the same identity) so that they can decrypt it. I recommend reading this other question for a wider background on how WhatsApp (and Signal) perform group chats. One critical factor here is that the identity key is only used to sign the prekey, which is effectively a surrogate for the identity key which can be rotated periodically. This means that the long-term key itself is never used to sign bulk data, which limits its exposure significantly and allows for it to be expunged from memory after a prekey is signed.
The ratchet part of the algorithm refers to some cryptographic processes which allow for keys to be continually derived in a chain. These processes allow an individual derived key to become compromised without compromising other keys in the chain. There generally need to be multiple different key compromises of different types in order to more completely compromise the chain and decrypt prior and future messages. This results in a number of forward secrecy properties for messages.
To answer your questions more directly: the identity key is security-critical (although there are ways to recover from a compromised identity key) but it does not impact forward-secrecy directly. The public part of the identity key is published to the Signal servers, but the private part is intended to stay on the device. Exchanging the private key to a new device is done via QR code or similar (implementation specific) and is generally considered secure because it is a local physical operation.
