WHEREAS:
-
@@ -49,7 +52,7 @@
The OMEMO protocol is an adaptation of the Signal Protocol, created by Open
+ Whisper
+ Systems
The predominant part of this report, the protocol security analysis, can be found
+ in Section 2, in which I analyze the full OMEMO protocol, including the used
+ Signal protocol and the protocol for encrypted file transfer. Section 3
+ discusses the results of a brief inspection of the open-source code
+
OMEMO is a recursive acronym that stands for “OMEMO Multi-End Message and
+ Object Encryption”. In this report, the term OMEMO refers to the
+ protocol as specified by its ProtoXEP
In order to eliminate confusion, Open Whisper Systems has very recently
+
Throughout this report, I will follow the tradition in cryptographic + literature of naming the end-users Alice and Bob, while reserving + the name Eve to represent the adversary. Note that the end-users + represent persons, not the device (or multiple devices) that they + use.
+Section 2 of the OMEMO ProtoXEP lists only a few requirements for the
+ protocol. From a cryptographic perspective, many basic requirements
+ are missing, including the basic CIA triad
To claim that the protocol is secure, a well-defined attacker model is + required in order to specify what the protocol is secure + against. By defining the goals that adversaries might + have and defining their capabilities, it becomes clear what the + protocol needs to defend against and which security properties it + should provide to the end-users.
+The attacker goals are closely tied to the security properties of + the secure messaging protocol. Table 1 lists the different + goals that an attacker might have and the corresponding + security property that a protocol should provide in order to + be considered secure.
+Table 1: Attacker Goals
+| Attacker Goal | +Security property | +
|---|---|
| Compromise messages | +Confidentiality of messages | +
| Alter sent messages | +Integrity of messages | +
| Inject false messages | +Authenticity of messages | +
| Identify as another person | +Authentication of communication partner | +
| Block communication | +Availability of communication | +
| Learn communication metadata | +Privacy protection | +
| Prove what was said | +Deniability of message content | +
| Prove that two persons communicated | +Deniability of the conversation | +
| Learn past communication after compromise | +Forward secrecy | +
| Prolong a successful attack | +Future secrecy | +
Not every attack can be defended against by a secure messaging + protocol. It is especially hard to provide availability when + an attacker is assumed to be able to block messages on the + communications network. Having said that, the protocol + should not make it easy for an attacker to block + communication.
+To protect the privacy of the users, the protocol should not leak + metadata about the users’ communication, such as who they + are communicating with, how many messages they sent and from + where. Communication layers below the secure messaging + protocol might leak this data as well, but it could be + hidden through anonymity tools such as Tor. In that case, + the protocol itself should not reveal any metadata.
+To provide deniability, it should be impossible for anyone to + provide convincing proof to a third party about past + communication. To deny that any conversation ever took place + is a stronger claim than just denying the precise contents + of a message.
+Forward secrecy
A base model for the attacker is the Dolev-Yao model
+
However, real attackers have capabilities beyond control over the + network. By inspecting the physical properties of the + implementation, they might learn secret information that is + on the communication device. This is called a side-channel + attack. Device compromises can also be achieved by low-tech + attacks such as a rubber-hose attack or through legal + procedures. An attacker is assumed to learn information + through side-channels and to be able to get temporary access + to the device.
+An issue with some existing protocols is that users need to trust + in the communications server that is being used. The open + nature of XMPP allows arbitrary parties, including + adversaries, to set up a fully functional XMPP server. But + even if you trust the organization that runs the server, you + might not trust the government of the country in which the + server is located to protect your privacy. Therefore, the + attacker is assumed to have full control over the server + that is used for communication.
+The last capability that is given to the attacker is to + compromise protocol participants themselves. When Alice + communicates with Bob, the protocol should provide some pro- + tection in case Bob turns out to be a dishonest participant. + Basically, the protocol should enforce Bob to play by the + rules.
+The OMEMO standard is best described as a wrapper protocol around the Signal
+ protocol. I will analyze the standard as specified by its ProtoXEP
+
In Section 2.1, I will first briefly inspect the Signal Protocol, to see how it + achieves its security properties. Those already familiar with the Signal + Protocol might want to skip this section. After that, Section 2.2 will fully + analyze how the OMEMO protocol uses the secure sessions created by Signal to + set up an OMEMO session between multiple devices of two users.
+At the moment of writing, version 3 is that latest version of the Signal + Protocol. This is the version that is used by OMEMO version 0 and the one + that is analyzed in this report.
+Although the Signal Protocol is mentioned in the specification, there is
+ no reference given to this protocol.
+ A simplified representation of the Signal Protocol is given in + Figure 1. The figure shows the start of a conversation + between Alice and Bob. In this abstracted example, the + participants are identified by their name. In reality, this + would be a phone number for the Signal application and an + XMPP address in case of OMEMO.
+Notation The following notation is used: + KDFs(i) derives a key using + salt s, info data i and a constant label that + is unique for each KDF computation in the figure. When no + salt is specified, the constant value 0 is used. + MACk(m) computes an + authentication tag on message m, using key k. + enck (n, m) + computes the symmetric encryption of message m, using + key k and nonce/initialization vector n. To + keep the diagram simple, the precise meaning for asymmetric + keys notation depends on the context, but it is + straightforward. For example: a0 refers to + the entire key pair when generated, to the private key when + used in the DH computation and to the public key when sent + in the message. Only public keys are sent in messages.
+Prekeys First Bob uploads his client-side generated key + material to the server so that he can be contacted by Alice. + He sends his long-term identity key B, his signed + prekey b0 with corresponding signature + sigB(b0) and a + one-time-use prekey bx. Bob can go offline + at this point, the server will now act as an online cache + for others that want to initiate a conversation with + Bob.
+TripleDH When Alice wants to talk with Bob, she requests
+ the cached data from the server. The server complies and
+ Alice can initiate the TripleDH
DH ratchet (every reply) Alice updates the root key with + the DH ratchet. She first generates a fresh random key pair + a1 and does a DH computation with + the latest DH key she received from Bob (initially + b0). Using the previous root key + rk0 as a seed for the KDF, she computes a + new root key rk1 and a new sending chain key + ck1,0. At this point, Alice should delete + the old root key rk0 and her previous key pair + a0 to ensure forward secrecy.
+Chain ratchet (every message) Alice derives a message key + (mk1,0) and a new chain key + ck1,1 from the old chain key + ck1,0 and she deletes the old chain key + for forward secrecy. Alice derives three keys from the mk + with the KDF: an encryption key k, an authentication + key m and a nonce/initialization vector n. She + encrypts the plaintext message and computes an + authentication tag over the (public) identity keys and the + ciphertext. She then sends the SignalMessage to Bob, + consisting of her one-time key a1, the + ciphertext and the authentication tag. Only with the + PreKeySignalMessage (the first message) will she also + include her first one-time key a0 and her + identity key A. Bob can use the key material from the + PreKeySignalMessage to initiate the root ratchet and + receiving chain ratchet, from which the key material can be + derived to validate and decrypt the message.
+This diagram implicitly also shows how the conversation + continues. Every time the user replies to a message, the + steps below the first horizontal line are taken: the root + key is updated with a fresh random DH computation and a new + sending chain ratchet is initialized. For every additional + message, the sending chain key is updated and a fresh + message key is used to encrypt user messages. Note that both + users have one root ratchet and two chain ratches: one for + sending and one for receiving.
+Key verification In order to ensure that no + man-in-the-middle attack has taken place, Alice needs to + verify that the identity key she has connected with indeed + belongs to Bob. How they do this is not important, as long + as it happens over an authenticated channel, but no PKI is + assumed in the protocol. Instead, users must manually verify + the identity key “fingerprint” (which is just the full + public key) of the other party.
+Message counters Messages might arrive out of order and + can even arrive after the DH ratchet has been forwarded. + Therefore, the sender of the message also includes two + counters: one for how many messages were sent under the + current ratchet and one for the total under the previous + ratchet. With these counters, the receiver can see exactly + which messages did not (yet) arrive and store only the + corresponding message key mk. These counters are + authenticated by the tag, but they are not encrypted.
+Multiple prekeys In a real-world situation, Bob would want + more than one person to be able to communicate with him, so + he uploads multiple prekeys to the server. In the case of + the Signal application, Alice only gets a single one-time + prekey from the server. When the server runs out of prekeys, + Alice can complete the handshake without Bob’s one-time + prekey. This message has reduced forward secrecy, because + Bob cannot delete the signed prekey b0 immediately after + use. When Bob receives a PreKeySignalMessage, he should send + a fresh signed prekey to the the server, so that the key + that is cached on the server gets updated.
+Bob needs to know which signed prekey and which one-time prekey + Alice used in her computation, so each prekey has its own + identifying number. Alice includes that number in the + PreKeySignalMessage and sends Bob, unauthenticated and + unencrypted. These numbers are generated sequentially.
+Key lifetimes The identity key lasts indefinitely. It is + possible that Alice sends a message using a signed prekey + that was already updated by Bob. For that reason, Bob should + keep a few old signed prekeys in storage, so that he does + not need to discard those messages. How long this should be + is not specified, but the specification should include at + least a guideline and/or upper bound for this lifetime. The + one-time prekeys are used only once and should be deleted + immediately after use. The server should delete a public + one-time prekey immediately after they handed it out to + someone, so it does not get used again. DH ratchet keys + should be deleted after the other party has sent their next + DH ratchet key and that DH computation has been + completed.
+Used cryptographic primitives The protocol so far is + lacking a description of which cryptographic primitives are + used as building blocks of the protocol. Technically, the + protocol does not need to be locked, but at this moment it + is non-trivial to change the used ciphers in the OWS code. + The following primitives are in use:
+-
+
- enc: AES
in CBC mode and using + PKCS5padding
+ - MAC: HmacSHA256
- KDF: HKDF
using HmacSHA256
+ - DH: X25519
- sig: Ed25519
A standard of the protocol could benefit from allowing different + primitives or cipher suites. For example, when a + cryptographic breakthrough leads to breakage of a primitive, + clients can simply reject all suites that use that primitive + and remain secure. Or an implementer might want to use a + different suite because of business requirements or + performance issues. This cipher suite should be negotiated + at the start of the protocol: Bob can upload a list of all + suites he accepts to the server cache and Alice can pick + one. To avoid downgrade attacks, the full list and the + picked suite should be authenticated in the + PreKeySignalMessage.
+Note that the identity key B is used both for signing
+ prekeys and in a DH computation, which is secure
+
Metadata The protocol leaks metadata about who is + communicating with whom and how much they are communicating. + Alice’s request for the server cache leaks to the server + that she wants to start a conversation with Bob, as does the + PreKeySignalMessage. The plaintext message counters that are + included in each SignalMessage make it possible to track the + rest of the conversation.
+Unlike the ratchet used in the Signal Protocol, the regular
+ variant of the Double Ratchet
A more thorough analysis of the Signal protocol has been done
+ before by Frosch, Mainka, Bader, Bergsma, Schwenk and Holz
+
In their analysis, the researchers found no major weaknesses in + the Signal Protocol. They give security proofs for the + building blocks that make up the Signal Protocol: the + initial key exchange, the subsequent key derivation and the + authenticated encryption. In addition, they identify a minor + weakness in the authentication of users identity keys, named + the unknown key-share attack, and they comment on the + claimed additional security features (future secrecy, + forward secrecy and deniability).
+Unknown key-share attack In an unknown key-share attack,
+ Eve downloads the public key material of Bob and uploads the
+ keys as if they are her own. When Alice wants to initiate a
+ conversation with Eve, she checks that the identity key she
+ downloaded from the server match with the one that Eve
+ presents to her out-of-band. Alice completes the handshake
+ on her side and sends here initial messages. Eve forwards
+ these (still encrypted) messages to Bob.
The result of a successful attack is that Alice falsely believes + that she sent her messages to Eve, while Bob falsely + believes that the received messages were intended for him. + Eve is unable to compromise the confidentiality or integrity + of the messages, making the impact of this attack relatively + low.
+The underlying cause of the above attack is that Eve never needed + to prove to Alice that she was in possession of the private + key corresponding to the presented identity public key. The + researchers propose a solution, where the users engage in an + out-of-band interactive zero-knowledge proof over an + authenticated channel, such as exchange of messages with + QR-codes. Because this solution is based on an interactive + protocol, it would disable users from sending messages + immediately if the recipient is not online at that + moment.
+Future secrecy Future secrecy ensures that a key + compromise at some point in time will not propagate + indefinitely. The Signal protocol achieves this by + introducing new randomness with every reply in order to + forward the root ratchet. A key compromise by a passive + attacker will not propagate from that point on. However, an + active attacker that has compromised both the root key and + an identity key is able to set up a man in the middle attack + that can be prolonged indefinitely.
+Forward secrecy Forward secrecy ensures that when a device + is compromised, no past messages can be decrypted. This is + achieved by erasing message encryption/decryption keys as + soon as possible. One of the problems with the Signal + Protocol is that Bob’s private prekeys need to remain stored + on the device until a message has been received that was + encrypted with the corresponding public prekey. If Eve + manages to intercept and block that message from being + delivered, Bob will keep holding on to that private prekey, + so that Eve can read the content of the message if she is + able to extract Bob’s private prekeys from his device. But + for any message that is delivered and decrypted correctly, + Bob discards the private part of the prekey and ensures + forward secrecy.
+Version 2 of the Signal Protocol was also vulnerable to an attack + on the forward secrecy of the first message by an active + adversary. Eve could provide her own prekey (of which she + knew the corresponding private key) and provide it to Alice, + pretending it was the prekey of Bob, together with Bob’s + identity key. Bob would not be able to decrypt the message, + but Eve would be able to if she was able to compromise just + Bob’s private identity key. Version 3 fixes this + vulnerability by introducing adding a prekey that is signed + by the identity key. This signature ensures that Eve cannot + provide her own prekey and pretend that it belongs to Bob, + thus preventing the attack.
+Deniability Deniability for a messaging application can + occur on two levels: denial of the message content and + denial of the full conversation. The researchers prove that + the Signal Protocol achieves the former, but they claim that + the latter might only be theoretical. Because clients + authenticate to the Open Whisper Systems server (similar to + how an XMPP client authenticates to an XMPP server) and this + server needs to know the addresses of the sender and + recipient in order to guarantee delivery, the logs that + might be stored by the server can reveal that a conversation + took place.
+The fact that a conversation took place might leak, but through + another layer than the application layer of the core Signal + Protocol. The solution to such leaking of metadata should + also be contained in the appropriate layer and should stay + out of scope for the OMEMO specification.
+OMEMO uses Signal in order to set up a session. In Section 2.2.1, I will + show how OMEMO uses those Signal sessions in order to set up a + secure conversation between multiple devices. In Section 2.2.2, I + will analyze the cryptographic strength of the design and describe + minor issues I found in the specification. Two major problems are + described in their own sections: Section 2.2.3 explains how a + malicious device can compromise the entire conversation and Section + 2.2.4 shows how forward secrecy and future secrecy can be affected + by other devices.
+At a very high level, OMEMO works similar to how a Signal group
+ messages
A complete overview of OMEMO is given in the use cases of section + 4 of the ProtoXEP, but I will provide a brief description + here. A typical XMPP setup is shown in Figure 2. Alice is + registered at a different server as Bob. Alice has + registered two OMEMO enabled devices, while Bob has only + registered his phone and wants to register his laptop as + well.
+In order to register his laptop, Bob generates a random 31-bit + device id and registers it by adding it to his device list + on the server via PEP. He then generates a random identity + key B, a signed prekey b0 with + corresponding signature sig(b0) and 100 + one-time prekeys bx. He then + uploads this in an OMEMO bundle, again via PEP. This bundle + contains the same information that Bob caches on the server + in regular Signal.
+Assume Alice wants to send an OMEMO encrypted message from her
+ phone. She can detect that Bob’s device(s) support OMEMO by
+ requesting his device list with PEP. If he does, she
+ encrypts and authenticates her message using a randomly
+ generated key. For every device that Alice wants to send the
+ encrypted message to, she fetches the entire bundle via PEP.
+ If she wants to add more of her own devices in the
+ conversation, she gets their bundles as well from her own
+ server. Alice creates a PreKeySignalMessage for every device
+ by picking a random one-time prekey from each bundle and
+ encrypting the randomly generated key to each device. She
+ combines all information in a single MessageElement: the
+ encrypted payload (
+ Bob’s device can decrypt the message by selecting the correct
+
At this point, Alice’s phone has set up a Signal session with + each of the devices. If Bob wants to reply, he still needs + to initialize a session with Alice’s PC, so he also needs to + download all bundles and initialize Signal sessions by + sending a PreKeySignalMessage where necessary. If all + devices (but one) have sent a message, each device will have + a pairwise Signal session set up.
+Device synchronization The regular delivery mechanism of
+ XMPP was built to send a message to one user only and to
+ send it only to online devices. Message Carbons
+
The MAM was designed as a message archive, but instead it is used + here as a message cache. The ciphertext messages will remain + stored online after they have been downloaded, even though + the keys will be discarded upon encryption. This does not + affect security, but it wastes space on the server. A client + should delete the message from the server after they + decrypted it and deleted the message keys.
+KeyTransportElement Instead of sending a MessageElement, a + device can also send a message without a payload, called a + KeyTransportElement. The randomly generated key might be + used for example to encrypt a file, see Section 2.3. Sending + a KeyTransportElement also has the advantage that the Signal + ratchet gets forwarded.
+Prekey collision When Alice wants to create a + PreKeySignalMessage for Bob, she gets the full bundle and + randomly selects one of his prekeys. When Bob receives + multiple PreKeySig- nalMessages, the prekeys might collide. + Because of the birthday problem, collisions are expected to + occur often. With 100 prekeys a collision is expected after + 12.3 PreKeySignalMessages and for the suggested minimum of + 20 keys, a collision is expected after approximately 5.86 + PreKeySignalMessages.
+When Bob receives PreKeySignalMessages with prekey collisions, he + replies to Alice with a KeyTransportElement containing his + own PreKeySignalMessage, so that a new session can be + initiated. If Bob no longer has the corresponding private + prekey, he silently discards the message.
+When fetching a PreKeySignalMessage with MAM, Bob should keep the
+ private prekey in memory (but he may also delete them) until
+ all MAM messages have been downloaded, so that he can still
+ decrypt messages. He can decrypt, but he should set up a new
+ session with Alice anyway. The specification warns for a
+ small subgroup attack
A more elegant solution would be to do what OWS does: let the + server send each one-time prekey once and delete them + afterwards, instead of delivering the entire list of + prekeys. That way, no collisions can occur on the prekeys + and fewer initial messages get dropped. When the server runs + out of one-time prekeys, the server lets Alice know and she + can complete the PreKeySignalMessage without a one-time key, + just as the Signal application.
+It is unclear if this solution is possible to implement in XMPP, + as it appears that there currently is no XMPP extension that + allows a server to delete/mark PEP nodes while the user is + offline.
+Device ID The resourcepart of the XMPP address
Colliding device ids do not affect the security of the protocol: + in the worst case, colliding devices are unable to + participate in the conversation, affecting only the + usability.
+The pairwise Signal session in OMEMO are very similar to that of + the Signal application, so their security properties are + similar. The server model for XMPP is slightly different as + that of OWS, but since the protocol does not rely on trust + in the server this should not affect the security of the + Signal sessions. The way that multiple Signal sessions are + combined to create a multi-device OMEMO session does affect + the security properties of the entire protocol, so I will + analyze that in this Section.
+Signed prekey lifetime OMEMO does not specify when a + signed prekey should be renewed on the server. When this key + does not get updated, the forward secrecy of a PreKeySig- + nalMessage is not protected against an active attacker (see + Section 2.1.2). The device should send a fresh key to the + server regularly and old signed prekeys should be deleted + from the device after a while.
+Cryptographic primitives OMEMO adds only one cryptographic + primitive: authenticated encryption of the payload, which is + fixed to AES in GCM mode. There is no reason to fix the + cipher for OMEMO, any form of encryption with authentication + can be used. A non-authenticated encryption cipher can also + be used when the payload authentication is included in the + tag of the SignalMessage, as described in Section 2.2.3.
+The specification should allow for alternative ciphers, for the + same reason that the Signal protocol should. Preferably, the + negotiation of this cipher should be merged with that of the + negotiation of the Signal cipher suite, so that clients only + need to negotiate this once at the start of a conversation. + Unfortunately, Signal is not standardized and it would + probably be unwise to specify in the OMEMO standard how + Signal should negotiate its primitives.
+Metadata Communication metadata is already leaked through + the Signal protocol and probably also through the XMPP + transport layer, but OMEMO also leaks this information + through the plaintext device ids. The payload is encrypted + in GCM mode, so the size of the plaintext is also + leaked.
+One cannot expect messages to remain confidential when one of the + participating devices is malicious. However, a user might + suspect at least that the integrity of messages sent by an + honest device is guaranteed by the protocol. After all, a + secure Signal session with that honest device has been set + up. However, the Signal session only protects the random + key. A malicious device has access to that key and can thus + re-encrypt and re-authenticate any payload with that key, + without the receiving party being able to detect it. This is + illustrated in Figure 3.
+ The displayed attack only shows the attack in one direction: Eve
+ is able to modify and read anything sent by Alice. Eve needs
+ to apply the same attack to Bob in order to setup up a
+ bidirectional man in the middle attack. Note that Eve needs
+ to strip of her own
+ Two careful users will not be susceptible to this attack, because + neither of them will ever accept an unvalidated key. + However, no matter how careful Bob is with validating the + identity key of the sending device, he must assume that + Alice has never made a mistake and none of the devices were + compromised in order to be guaranteed the authenticity of + messages that come from any of her devices. This trust in + the other party is not necessary, if the messages were + authenticated inside the Signal session. Also, Bob could + make it less likely for Alice to accept a malicious device + by creating a cryptographic link between devices.
+Message authentication Messages are authenticated by the + randomized key, which protects the message integrity from + outsiders. However, anyone with access to the key can alter + the message, which includes a malicious device. There are a + few possible mitigations, each with their advantages and + disadvantages.
+ A possible solution would be to authenticate inside the Signal
+ session. By authenticating the payload with the tag of the
+ SignalMessage, the full message is authenticated in such a
+ way that no other device can compromise the integrity. The
+ ciphertext (and not the plaintext) of the payload message
+ should be authenticated, so that the MAC-then-encrypt
+ pattern is applied.
The payload can also be authenticated by including a hash of the
+ payload ciphertext in the SignalMessage plaintext (and
+ therefore the corresponding encrypted hash in the SignalMes-
+ sage ciphertext). This would not require changes to the
+ Signal library, but it would increase the size of each
+
By authenticating a list of all recipient device ids in the tag + of the SignalMessage, Bob has a guarantee about which + devices Alice has sent the message to. Bob’s client might + provide him with a warning if that list includes untrusted + devices. This protects him against the specific attack + described above, but the protocol remains vulnerable if one + of the devices gets compromised by another attack. This + solution can be combined with the above solution of + authenticating the payload ciphertext with the SignalMessage + ciphertext or tag.
+Device linkage There is no cryptographic link between + identities and device keys. In other words, Eve can attach + her own device identity key as if it is a resource belonging + to Bob and fool Alice into adding it.
+There is a solution: each device could sign a certificate on + each device identity key of the same user. While Eve might + fool Alice into thinking that Bob has another device, it is + highly unlikely that Bob is tricked into accepting another + device as his own. Device identity keys with a certificates + that was signed by an already accepted device of the same + user could be accepted automatically.
+In order to account for compromised devices, users must have the + ability to revoke certificates and certificates should have + a finite lifetime. This solution can be extended into a + full-blown public key infrastructure (PKI) or web of trust, + but I recommend to keep that out of the scope of the OMEMO + specification (although compatibility with such systems + could be taken into account when updating the OMEMO + specification).
+The forward secrecy and future secrecy of the protocol might be + affected in unexpected ways when a user has read-only + devices or inactive devices.
+Read-only devices Read-only devices will forward their + Signal chaining key, but never is there any message sent + from these devices, so the Signal root key will never be + ratcheted forward. Such a device compromises the future + secrecy of the entire conversation: if the receiving + chaining key of such a device gets compromised, the rest of + the conversation from that point on is compromised.
+The solution is simple, the read-only device should regularly + send a KeyTransportElement in order to forward the ratchet. + The interval for this message can be based on a number of + received messages, on time, or on a combination of + these.
+Inactive devices Devices that are no longer used and never + come online anymore, should be pruned from the conversation: + they keep a copy of a very old chain key in their memory, + which compromises the forward secrecy of the entire + conversation. There is currently no way specified for + removing keys from a conversation, except for just removing + them.
+A device can interpret the above message for read-only devices as + an authenticated heartbeat message. When the device has not + not received a heartbeat for too long, it can decide to + prune the device from the conversation.
+The OMEMO Encrypted Jingle File Transfer is defined in its ProtoXEP
+
From a cryptographic perspective, there is no difference between sending + an OMEMO text message and sending an OMEMO-encrypted Jingle file, + even if that file gets sent over another channel. The one difference + is that Jingle allows for some file metadata to be sent. This + metadata is neither encrypted nor authenticated. The specification + does not provide a method for encrypting the metadata as well.
+Message authentication Just as a normal message is not + authenticated in the presence of a malicious device (see Section + 2.2.3), so is the file content not authenticated when a malicious + device is present.
+ The earlier proposed solution for authenticating the payload
+ (authenticating the ciphertext in the SignalMessage tag) would
+ disable on-the-fly encryption when sending a file, because the
+ payload ciphertext must be known when constructing the
+
Metadata Even though the metadata is not secured by the
+ specification, it should not leak any information on the raw file
+ contents. The Jingle protocol requires a hash of the file. The OMEMO
+ file-transfer specification is correct in requiring that this hash
+ is of the file ciphertext: a plaintext hash would lead to a
+ “confirmation-of-data” vulnerability
All other metadata can simply be removed from the
+
Conversations is an open-source
The Conversations code simply uses the Signal library by OWS. Generation of
+ Signal keys, encryption of
Key generation for the Signal keys (identity key, prekeys and ephemeral keys) is
+ handled by the Signal library. The random key for the OMEMO payload is
+ generated by
The Conversations application does not keep prekeys in memory during a MAM + catch-up. Instead, the application uses the Signal library, which always + deletes the keys from the store after decryption of a + PreKeySignalMessage.
+
+ HTTP file upload Instead of using the OMEMO encrypted Jingle File
+ Transfer as a default method for file transfer, the application gives
+ preference to HTTP upload
+ X509 certificates The code allows X509 certificates on identity keys, + although this is currently disabled by default. I have not looked in to much + detail, as this is outside the scope of the OMEMO specification, but there + appears to be nothing wrong with this approach.
++ Purge The conversations application allows users to purge the key of + other devices, which says that it irreversibly marks the key as compromised. + This irreversibility is not guaranteed and is only enforced by the fact that + the application provides no user interface for reversing. Users have no + method for purging their own keys or otherwise marking them as + compromised.
++ Group messages The Conversations application allows for group + conversations, although this is not specified by the ProtoXEP. From a + cryptographic perspective, these multi-user chats are no different from a + multi-device chat: to send a message to all users, the sending device will + have to set up a Signal session with each of the participating devices, + regardless of the user to which the device belongs.
+The OMEMO standard provides a protocol for secure communication with multiple + devices. This protocol is only secure if both users apply good operational + security in securing their devices and in adding devices of the other + party.
+When both users are careful, they can set up a secure multi-device session. + However, if one of the users makes a mistake and adds a malicious device, or + if just one device of the users gets compromised, the authentication of all + messages is compromised, which is not necessary. The (ciphertext of the) + payload should be authenticated in each SignalMessage, preferably as + AAD.
+The current OMEMO specification provides no link between devices that belong to + the same user. Eve might trick Alice thinking that her key belongs to Bob. + Bob should be able to sign a certificate that tells Alice which devices + belong to him, she would not be tricked so easily by Eve.
+Each devices should regularly send a message (a heartbeat) in order to forward + the root ratchet of the Signal sessions, so that future secrecy can be + ensured. The already existing KeyTransportElement can be used as an empty + message that achieves this functionality.
+Inactive devices, devices that never come online anymore, should be removed from + a conversation by the owning user. Their presence in a conversation means + that the forward secrecy of the entire conversation is compromised, because + they hold on to an old key. In addition, I recommend that inactive devices + may be removed by the other user. The above described heartbeat would + provide users with a method for detecting if a device has become + inactive.
+The lifetime of (signed) prekeys should be mentioned in the standard. Signed + prekeys should be changed regularly in order to achieve forward secrecy. + This should at least be done after every time the user receives a + PreKeySignalMessage that uses the latest signed prekey, but it can be done + more often (based on time) to ensure the forward secrecy of dropped + messages. The standard should allow for alternative ciphers. However, the + standard should limit itself to the ciphers used in the OMEMO encryption. + Signal also has no way for specifying ciphers, but it is not in the scope of + the OMEMO standard to specify that.
+Prekey collisions can be greatly reduced if the server hands out each key only + once, instead of all keys to every user that asks. This would not affect + security, but it would make successful delivery of the first message of the + protocol more reliable.
+The specification should update its terminology to reflect the recent name + changes by Open Whisper Systems. Specifically, the term “Axolotl” should be + replaced with “the Signal Protocol” and the message names + “PreKeyWhisperMessage” and “WhisperMessage” should be replaced with + “PreKeySignalMessage” and “SignalMessage”.
+My final remark is about the reference implementation. Unless a change is made + in the way that servers provide the keys, the code should not accept + PreKeySignalMessages without a one-time prekey. As stated before, this has + already been fixed in commit cc209af.
+I would like to thank Daniel Gultsch for helping me out with some of the + questions I have had on the protocol and for his quick processing of my + feedback in the Conversations code.
+During my review of the OMEMO documentation, I noted some minor errors in the + specification, most of which are typographical errors. This appendix + contains a list of corrections. None of these errors affect the security of + the protocol in any way.
+In the OMEMO XEP:
+-
+
- Section 4.5: both own devices (should be: both owned devices) +
- Section 6: axoltol (should have been: axolotl; should be: “the Signal + Protocol”) +
- Appendix G: duplicate references +
- Inconsistent usage of “.” (period) at the end of list items +
In the OMEMO file transfer XEP:
+-
+
- Section 3: Remeo and Juliet (should be: Romeo and Juliet) +
- Section 3: file tranfer (should be: file transfer) +
- Section 3, Example 1:
</file> has wrong + indentation
+ - Section 5: intilization (should be: initialization) +
- Section 5: the hash of encrypted file (should be: the hash of the + encrypted file) +
- Section 5: rangend tranfer (should be: ranged transfer) +
- Section 7: might not the Device ID (should be (?): might not have) +
- Section 8: Last list item is missing a “.” (period) +
- The document is missing a reference to the OMEMO XEP +
...
+This report contains our findings as well as detailed explanations of exactly + how ROS performed the penetration test.
+The scope of the penetration test was limited to the following target:
+...
+The Security Audit took place between X and Y, 2016.
+Through automated scans we were able to gain the following information about the + software and infrastructure. Detailed scan output can be found in the sections + below.
+As part of our active reconnaissance we used the following automated + scans:
+-
+
- nmap – http://nmap.org + + +
We have identified the following issues:
+ + + + + + +In this section we list some of the things that were tried but turned out to + be dead ends.
+This contract shall be effective as of
In case of tacit extension of this contract, the parties agree to do so for the same term and on the same conditions. Either party is entitled to give notice of termination of the contract with immediate effect. Notice of termination should be given by email. (To
In case of tacit extension of this contract, the parties agree to do so for the same term and on the same conditions. Either party is entitled to give notice of termination of the contract with immediate effect. Notice of termination should be given by email. (To
Premature termination shall not give rise to liability or financial compensation for either party.
- for ensuring that any work performed in the course of +
- The
is responsible: - for ensuring that any work performed in the course of this agreement is lawful (in Dutch: “rechtmatig”) and not illegal (in Dutch: “niet strafbaar”);
- for ensuring that by performing the Activities,
does not act contrary to a non-compete- or a confidentiality obligation may have. If there is a risk that - the Consultant will act contrary to such an obligation, will inform + the will act contrary to such an obligation, will inform without delay. then has the right to terminate the agreement without compensation; - and for paying any applicable taxes and social security premiums following from the
- Activities. Should
have to pay any of these, the Consultant will indemnify + Activities. Should have to pay any of these, the will indemnify .
diff --git a/xml/source/snippets/contract/en/ag_retainrights.xml b/xml/source/snippets/contract/en/ag_retainrights.xml
index 4b9e32e..817fac0 100644
--- a/xml/source/snippets/contract/en/ag_retainrights.xml
+++ b/xml/source/snippets/contract/en/ag_retainrights.xml
@@ -1,2 +1,2 @@
- - The Consultant retains all intellectual property rights
owns prior to this agreement.
+ - The
retains all intellectual property rights owns prior to this agreement.
diff --git a/xml/source/snippets/contract/en/ag_thirdparty.xml b/xml/source/snippets/contract/en/ag_thirdparty.xml
index 680e745..ab618af 100644
--- a/xml/source/snippets/contract/en/ag_thirdparty.xml
+++ b/xml/source/snippets/contract/en/ag_thirdparty.xml
@@ -1,2 +1,2 @@
- - Should a third party lodge a claim against
or any of its employees, freelancers or volunteers, or the public prosecutor initiate an investigation or criminal proceedings against any of these parties, as a result of activities performed by the Consultant under this agreement, then the Consultant will co-operate fully with in defending against this claim, investigation or these proceedings, including by providing any evidence he or she has which may be relevant to this defense.
+ - Should a third party lodge a claim against
or any of its employees, freelancers or volunteers, or the public prosecutor initiate an investigation or criminal proceedings against any of these parties, as a result of activities performed by the under this agreement, then the will co-operate fully with in defending against this claim, investigation or these proceedings, including by providing any evidence he or she has which may be relevant to this defense.
diff --git a/xml/source/snippets/contract/en/ag_workinghours.xml b/xml/source/snippets/contract/en/ag_workinghours.xml
index 0323bdf..d6feaff 100644
--- a/xml/source/snippets/contract/en/ag_workinghours.xml
+++ b/xml/source/snippets/contract/en/ag_workinghours.xml
@@ -1,2 +1,2 @@
- - The agreed working hours shall amount to
hours per . The Consultant may be expected to perform overtime outside the established working hours whenever this is necessary for the proper performance of the Activites.
+ - The agreed working hours shall amount to
hours per . The may be expected to perform overtime outside the established working hours whenever this is necessary for the proper performance of the Activites.
diff --git a/xml/source/snippets/contract/en/ag_worktime.xml b/xml/source/snippets/contract/en/ag_worktime.xml
index 08d6e20..45d4266 100644
--- a/xml/source/snippets/contract/en/ag_worktime.xml
+++ b/xml/source/snippets/contract/en/ag_worktime.xml
@@ -1,2 +1,2 @@
- - The Consultant will perform the Activities from
up to and including .
+ - The
will perform the Activities from up to and including .
diff --git a/xml/source/snippets/contract/en/parties.xml b/xml/source/snippets/contract/en/parties.xml
index 405ebab..74a71a5 100644
--- a/xml/source/snippets/contract/en/parties.xml
+++ b/xml/source/snippets/contract/en/parties.xml
@@ -3,4 +3,4 @@
has asked the Consultant to assist with this.
+has asked the to assist with this.
diff --git a/xml/source/snippets/contract/en/wa_contractorcan.xml b/xml/source/snippets/contract/en/wa_contractorcan.xml
index 912cff9..b8d46de 100644
--- a/xml/source/snippets/contract/en/wa_contractorcan.xml
+++ b/xml/source/snippets/contract/en/wa_contractorcan.xml
@@ -1,2 +1,2 @@
-- The Consultant is willing and able to perform the activities mentioned hereafter. +
- The
is willing and able to perform the activities mentioned hereafter.
diff --git a/xml/source/snippets/contract/en/wa_noemploymentintention.xml b/xml/source/snippets/contract/en/wa_noemploymentintention.xml
index c53066c..b163954 100644
--- a/xml/source/snippets/contract/en/wa_noemploymentintention.xml
+++ b/xml/source/snippets/contract/en/wa_noemploymentintention.xml
@@ -1,2 +1,2 @@
- and the Consultant have no intention whatsoever to agree upon an employment agreement and this agreement is only drafted to enable the Consultant to perform incidental activities for . and the Consultant explicitly confirm that this agreement does not qualify as an employment agreement. The Consultant is free to perform work for other parties, and in fact does so on a regular basis.
\ No newline at end of file
+and the have no intention whatsoever to agree upon an employment agreement and this agreement is only drafted to enable the to perform incidental activities for . and the explicitly confirm that this agreement does not qualify as an employment agreement. The is free to perform work for other parties, and in fact does so on a regular basis.
\ No newline at end of file
diff --git a/xml/source/snippets/contract/nl/ag_biggerscopewarning.xml b/xml/source/snippets/contract/nl/ag_biggerscopewarning.xml
index 140e70b..d5cfa4b 100644
--- a/xml/source/snippets/contract/nl/ag_biggerscopewarning.xml
+++ b/xml/source/snippets/contract/nl/ag_biggerscopewarning.xml
@@ -1,2 +1,2 @@
-- If during the course of the Activities, there is a risk that the scope of the assignment is bigger than expected, the Consultant will let
know without delay.
+ - If during the course of the Activities, there is a risk that the scope of the assignment is bigger than expected, the
will let know without delay.
diff --git a/xml/source/snippets/contract/nl/ag_companyinstructs.xml b/xml/source/snippets/contract/nl/ag_companyinstructs.xml
index 58a7ea9..971d487 100644
--- a/xml/source/snippets/contract/nl/ag_companyinstructs.xml
+++ b/xml/source/snippets/contract/nl/ag_companyinstructs.xml
@@ -1,2 +1,2 @@
- instructs (in Dutch: "wijst aan"; not "instrueert") the Consultant – and the Consultant agrees to perform the following activities (the “Activities”):
+instructs (in Dutch: "wijst aan"; not "instrueert") the – and the agrees to perform the following activities (the “Activities”):
diff --git a/xml/source/snippets/contract/nl/ag_generaltermsandconditions.xml b/xml/source/snippets/contract/nl/ag_generaltermsandconditions.xml
index a34ef2c..0acc178 100644
--- a/xml/source/snippets/contract/nl/ag_generaltermsandconditions.xml
+++ b/xml/source/snippets/contract/nl/ag_generaltermsandconditions.xml
@@ -1,2 +1,2 @@
-- The general terms and conditions of
apply to this agreement. rejects any general terms and conditions used by the Consultant.
+ - The general terms and conditions of
apply to this agreement. rejects any general terms and conditions used by the .
diff --git a/xml/source/snippets/contract/nl/ag_law.xml b/xml/source/snippets/contract/nl/ag_law.xml
index d649b5d..1a72a2f 100644
--- a/xml/source/snippets/contract/nl/ag_law.xml
+++ b/xml/source/snippets/contract/nl/ag_law.xml
@@ -1,2 +1,2 @@
- - Dutch law applies to this agreement. Any dispute between
and Consultant will be resolved in the first instance exclusively by the District Court (in Dutch: “rechtbank”) of Amsterdam, the Netherlands.
+ - Dutch law applies to this agreement. Any dispute between
and will be resolved in the first instance exclusively by the District Court (in Dutch: “rechtbank”) of Amsterdam, the Netherlands.
diff --git a/xml/source/snippets/contract/nl/ag_liability.xml b/xml/source/snippets/contract/nl/ag_liability.xml
index 04c8044..cb196c9 100644
--- a/xml/source/snippets/contract/nl/ag_liability.xml
+++ b/xml/source/snippets/contract/nl/ag_liability.xml
@@ -1,2 +1,2 @@
- - Unless a result of gross negligence or willful misconduct, the liability of either party to the other for any type of damages is limited to the amount of Consultant's total fees under Article 5 of this agreement. +
- Unless a result of gross negligence or willful misconduct, the liability of either party to the other for any type of damages is limited to the amount of
's total fees under Article 5 of this agreement.
diff --git a/xml/source/snippets/contract/nl/ag_noemployment.xml b/xml/source/snippets/contract/nl/ag_noemployment.xml
index 2972036..6228baa 100644
--- a/xml/source/snippets/contract/nl/ag_noemployment.xml
+++ b/xml/source/snippets/contract/nl/ag_noemployment.xml
@@ -1,3 +1,3 @@
- and the Consultant explicitly do not intend to enter into an employment agreement (in Dutch: “arbeidsovereenkomst”) as in Article 7:610 Burgerlijk Wetboek. The Consultant guarantees he shall never claim an employment agreement exists. + and the explicitly do not intend to enter into an employment agreement (in Dutch: “arbeidsovereenkomst”) as in Article 7:610 Burgerlijk Wetboek. The guarantees he shall never claim an employment agreement exists.
\ No newline at end of file
diff --git a/xml/source/snippets/contract/nl/ag_nondisclosure.xml b/xml/source/snippets/contract/nl/ag_nondisclosure.xml
index b585791..2e20f72 100644
--- a/xml/source/snippets/contract/nl/ag_nondisclosure.xml
+++ b/xml/source/snippets/contract/nl/ag_nondisclosure.xml
@@ -1,2 +1,2 @@
-- The Consultant will not disclose confidential information and personal data
receives from , or gains access to in the course of the Activities. The Consultant will only use this information or data for the purposes of carrying out this agreement. The Consultant will take reasonable measures to maintain the confidentiality of this information and data. The Consultant may disclose this information and data on a need-to-know basis, and only to persons associated with as employee, freelancer or volunteer and only if the Consultant knows that they are bound by the same confidentiality obligations.
+ - The
will not disclose confidential information and personal data receives from , or gains access to in the course of the Activities. The will only use this information or data for the purposes of carrying out this agreement. The will take reasonable measures to maintain the confidentiality of this information and data. The may disclose this information and data on a need-to-know basis, and only to persons associated with as employee, freelancer or volunteer and only if the knows that they are bound by the same confidentiality obligations.
diff --git a/xml/source/snippets/contract/nl/ag_ownrisk.xml b/xml/source/snippets/contract/nl/ag_ownrisk.xml
index b2736a2..1828ed0 100644
--- a/xml/source/snippets/contract/nl/ag_ownrisk.xml
+++ b/xml/source/snippets/contract/nl/ag_ownrisk.xml
@@ -1,2 +1,2 @@
- - The Consultant is working at his or her own risk (in Dutch: “voor eigen rekening en risico”). The Consultant is free to perform the Activities at his or her own discretion (in Dutch: “naar eigen inzicht”) and independently. The Consultant will use his own resources and tools to perform the Activities for
.
+ - The
is working at his or her own risk (in Dutch: “voor eigen rekening en risico”). The is free to perform the Activities at his or her own discretion (in Dutch: “naar eigen inzicht”) and independently. The will use his own resources and tools to perform the Activities for .
diff --git a/xml/source/snippets/contract/nl/ag_payment_fixed_term.xml b/xml/source/snippets/contract/nl/ag_payment_fixed_term.xml
index 6142e7b..c4983c5 100644
--- a/xml/source/snippets/contract/nl/ag_payment_fixed_term.xml
+++ b/xml/source/snippets/contract/nl/ag_payment_fixed_term.xml
@@ -1,3 +1,3 @@
-
-will pay the Consultant per hour excluding VAT. It will do so after has received an invoice from the Consultant. The Consultant will send an invoice within 14 days after the end of each calendar month for the Activities performed during that month. will then pay the agreed amount within 30 days of receipt of the invoice. will also pay reasonable travel expenses of the Consultant, to the extent that has given prior written approval for such costs and the Consultant provides with an invoice or other documentation for these expenses. will not reimburse any other costs the Consultant incurs in the course of the Activities, unless has given prior written approval for such costs. For the avoidance of doubt, shall pay no wages (in Dutch: "salaris") to the Consultant and therefore, shall not provide payslips to the Consultant, nor pay to the Consultant any money or allowance in the event of a holiday or illness of the Consultant.
+
+will pay the per hour excluding VAT. It will do so after has received an invoice from the . The will send an invoice within 14 days after the end of each calendar month for the Activities performed during that month. will then pay the agreed amount within 30 days of receipt of the invoice. will also pay reasonable travel expenses of the , to the extent that has given prior written approval for such costs and the provides with an invoice or other documentation for these expenses. will not reimburse any other costs the incurs in the course of the Activities, unless has given prior written approval for such costs. For the avoidance of doubt, shall pay no wages (in Dutch: "salaris") to the and therefore, shall not provide payslips to the , nor pay to the any money or allowance in the event of a holiday or illness of the .
diff --git a/xml/source/snippets/contract/nl/ag_payment_single_engagement.xml b/xml/source/snippets/contract/nl/ag_payment_single_engagement.xml
index 56f417b..ae79e24 100644
--- a/xml/source/snippets/contract/nl/ag_payment_single_engagement.xml
+++ b/xml/source/snippets/contract/nl/ag_payment_single_engagement.xml
@@ -1,3 +1,3 @@
-
-will pay the Consultant for a -hour engagement: per hour excluding VAT, therefore totaling excluding VAT. It will do so after has been paid for the assignment in the context of which the Activities took place and has received an invoice from the Consultant. The Consultant will send an invoice within 14 days after the end of each calendar month for the Activities performed during that month. will then pay the agreed amount within 30 days of receipt of the invoice. will also pay reasonable travel expenses of the Consultant, to the extent that has given prior written approval for such costs and the Consultant provides with an invoice or other documentation for these expenses. will not reimburse any other costs the Consultant incurs in the course of the Activities, unless has given prior written approval for such costs. For the avoidance of doubt, shall pay no wages (in Dutch: "salaris") to the Consultant and therefore, shall not provide payslips to the Consultant, nor pay to the Consultant any money or allowance in the event of a holiday or illness of the Consultant.
+
+will pay the for a -hour engagement: per hour excluding VAT, therefore totaling excluding VAT. It will do so after has been paid for the assignment in the context of which the Activities took place and has received an invoice from the . The will send an invoice within 14 days after the end of each calendar month for the Activities performed during that month. will then pay the agreed amount within 30 days of receipt of the invoice. will also pay reasonable travel expenses of the , to the extent that has given prior written approval for such costs and the provides with an invoice or other documentation for these expenses. will not reimburse any other costs the incurs in the course of the Activities, unless has given prior written approval for such costs. For the avoidance of doubt, shall pay no wages (in Dutch: "salaris") to the and therefore, shall not provide payslips to the , nor pay to the any money or allowance in the event of a holiday or illness of the .
diff --git a/xml/source/snippets/contract/nl/ag_period.xml b/xml/source/snippets/contract/nl/ag_period.xml
index 234dcf7..4af6fbb 100644
--- a/xml/source/snippets/contract/nl/ag_period.xml
+++ b/xml/source/snippets/contract/nl/ag_period.xml
@@ -1,4 +1,4 @@
This contract shall be effective as of
-for the period of . This contract will end by operation of law on without any notice being required. In case of tacit extension of this contract, the parties agree to do so for the same term and on the same conditions. Either party is entitled to give notice of termination of the contract with immediate effect. Notice of termination should be given by email. (To
+: ; to the Consultant: ) The other party will confirm the termination by return. In case of tacit extension of this contract, the parties agree to do so for the same term and on the same conditions. Either party is entitled to give notice of termination of the contract with immediate effect. Notice of termination should be given by email. (To
: ; to the : ) The other party will confirm the termination by return. Premature termination shall not give rise to liability or financial compensation for either party.
diff --git a/xml/source/snippets/contract/nl/ag_propertyrights.xml b/xml/source/snippets/contract/nl/ag_propertyrights.xml
index 2809150..cc5f4dc 100644
--- a/xml/source/snippets/contract/nl/ag_propertyrights.xml
+++ b/xml/source/snippets/contract/nl/ag_propertyrights.xml
@@ -1,2 +1,2 @@
-- The Consultant transfers to
all intellectual property rights created as a result of the Activities. To the extent that it is not possible to transfer these rights, grants to a perpetual, exclusive transferable, sub-licensable, world-wide license to such rights, and agrees to co-operate with the transfer of these rights to . To the extent that the Consultant has transferred these rights to , grants a perpetual, non-exclusive, non-transferable, not-sub-licensable, world-wide license to such rights to the Consultant, unless considers this impossible, due to obligations might have vis-à-vis others. In that case, will explore whether it is possible to grant to the Consultant a license on the rights with a narrower scope. For the avoidance of doubt, any rights of the Consultant vested in software or services developed prior to the Activities are not affected by this agreement.
+ - The
transfers to all intellectual property rights created as a result of the Activities. To the extent that it is not possible to transfer these rights, grants to a perpetual, exclusive transferable, sub-licensable, world-wide license to such rights, and agrees to co-operate with the transfer of these rights to . To the extent that the has transferred these rights to , grants a perpetual, non-exclusive, non-transferable, not-sub-licensable, world-wide license to such rights to the , unless considers this impossible, due to obligations might have vis-à-vis others. In that case, will explore whether it is possible to grant to the a license on the rights with a narrower scope. For the avoidance of doubt, any rights of the vested in software or services developed prior to the Activities are not affected by this agreement.
diff --git a/xml/source/snippets/contract/nl/ag_responsibilities.xml b/xml/source/snippets/contract/nl/ag_responsibilities.xml
index 1477107..34c8d1c 100644
--- a/xml/source/snippets/contract/nl/ag_responsibilities.xml
+++ b/xml/source/snippets/contract/nl/ag_responsibilities.xml
@@ -1,12 +1,12 @@
- - The Consultant is responsible:
- for ensuring that any work performed in the course of +
- The
is responsible: - for ensuring that any work performed in the course of this agreement is lawful (in Dutch: “rechtmatig”) and not illegal (in Dutch: “niet strafbaar”);
- for ensuring that by performing the Activities,
does not act contrary to a non-compete- or a confidentiality obligation may have. If there is a risk that - the Consultant will act contrary to such an obligation, will inform + the will act contrary to such an obligation, will inform without delay. then has the right to terminate the agreement without compensation; - and for paying any applicable taxes and social security premiums following from the
- Activities. Should
have to pay any of these, the Consultant will indemnify + Activities. Should have to pay any of these, the will indemnify .
diff --git a/xml/source/snippets/contract/nl/ag_retainrights.xml b/xml/source/snippets/contract/nl/ag_retainrights.xml
index 4b9e32e..817fac0 100644
--- a/xml/source/snippets/contract/nl/ag_retainrights.xml
+++ b/xml/source/snippets/contract/nl/ag_retainrights.xml
@@ -1,2 +1,2 @@
- - The Consultant retains all intellectual property rights
owns prior to this agreement.
+ - The
retains all intellectual property rights owns prior to this agreement.
diff --git a/xml/source/snippets/contract/nl/ag_thirdparty.xml b/xml/source/snippets/contract/nl/ag_thirdparty.xml
index 680e745..ab618af 100644
--- a/xml/source/snippets/contract/nl/ag_thirdparty.xml
+++ b/xml/source/snippets/contract/nl/ag_thirdparty.xml
@@ -1,2 +1,2 @@
- - Should a third party lodge a claim against
or any of its employees, freelancers or volunteers, or the public prosecutor initiate an investigation or criminal proceedings against any of these parties, as a result of activities performed by the Consultant under this agreement, then the Consultant will co-operate fully with in defending against this claim, investigation or these proceedings, including by providing any evidence he or she has which may be relevant to this defense.
+ - Should a third party lodge a claim against
or any of its employees, freelancers or volunteers, or the public prosecutor initiate an investigation or criminal proceedings against any of these parties, as a result of activities performed by the under this agreement, then the will co-operate fully with in defending against this claim, investigation or these proceedings, including by providing any evidence he or she has which may be relevant to this defense.
diff --git a/xml/source/snippets/contract/nl/ag_workinghours.xml b/xml/source/snippets/contract/nl/ag_workinghours.xml
index 0323bdf..d6feaff 100644
--- a/xml/source/snippets/contract/nl/ag_workinghours.xml
+++ b/xml/source/snippets/contract/nl/ag_workinghours.xml
@@ -1,2 +1,2 @@
- - The agreed working hours shall amount to
hours per . The Consultant may be expected to perform overtime outside the established working hours whenever this is necessary for the proper performance of the Activites.
+ - The agreed working hours shall amount to
hours per . The may be expected to perform overtime outside the established working hours whenever this is necessary for the proper performance of the Activites.
diff --git a/xml/source/snippets/contract/nl/ag_worktime.xml b/xml/source/snippets/contract/nl/ag_worktime.xml
index 08d6e20..45d4266 100644
--- a/xml/source/snippets/contract/nl/ag_worktime.xml
+++ b/xml/source/snippets/contract/nl/ag_worktime.xml
@@ -1,2 +1,2 @@
- - The Consultant will perform the Activities from
up to and including .
+ - The
will perform the Activities from up to and including .
diff --git a/xml/source/snippets/contract/nl/parties.xml b/xml/source/snippets/contract/nl/parties.xml
index 294de4d..aec7be0 100644
--- a/xml/source/snippets/contract/nl/parties.xml
+++ b/xml/source/snippets/contract/nl/parties.xml
@@ -3,4 +3,4 @@
has asked the Consultant to assist with this.
+has asked the to assist with this.
diff --git a/xml/source/snippets/contract/nl/wa_contractorcan.xml b/xml/source/snippets/contract/nl/wa_contractorcan.xml
index 912cff9..b8d46de 100644
--- a/xml/source/snippets/contract/nl/wa_contractorcan.xml
+++ b/xml/source/snippets/contract/nl/wa_contractorcan.xml
@@ -1,2 +1,2 @@
-- The Consultant is willing and able to perform the activities mentioned hereafter. +
- The
is willing and able to perform the activities mentioned hereafter.
diff --git a/xml/source/snippets/contract/nl/wa_noemploymentintention.xml b/xml/source/snippets/contract/nl/wa_noemploymentintention.xml
index c53066c..b163954 100644
--- a/xml/source/snippets/contract/nl/wa_noemploymentintention.xml
+++ b/xml/source/snippets/contract/nl/wa_noemploymentintention.xml
@@ -1,2 +1,2 @@
- and the Consultant have no intention whatsoever to agree upon an employment agreement and this agreement is only drafted to enable the Consultant to perform incidental activities for . and the Consultant explicitly confirm that this agreement does not qualify as an employment agreement. The Consultant is free to perform work for other parties, and in fact does so on a regular basis.
\ No newline at end of file
+and the have no intention whatsoever to agree upon an employment agreement and this agreement is only drafted to enable the to perform incidental activities for . and the explicitly confirm that this agreement does not qualify as an employment agreement. The is free to perform work for other parties, and in fact does so on a regular basis.
\ No newline at end of file
diff --git a/xml/source/snippets/localisationstrings.xml b/xml/source/snippets/localisationstrings.xml
index a24a6d6..b071a32 100644
--- a/xml/source/snippets/localisationstrings.xml
+++ b/xml/source/snippets/localisationstrings.xml
@@ -71,6 +71,14 @@
EN
-
\ No newline at end of file +, met adres op , , , (de “Consultant”);
\ No newline at end of file diff --git a/xml/source/snippets/contract/nl/wa_companyhasasked.xml b/xml/source/snippets/contract/nl/wa_companyhasasked.xml index 505f386..5ba07d9 100644 --- a/xml/source/snippets/contract/nl/wa_companyhasasked.xml +++ b/xml/source/snippets/contract/nl/wa_companyhasasked.xml @@ -1,2 +1,2 @@ -, met adres op , , , (de “ ”); security consulting agreement security consulting agreement ++ +in aanmerking genomen dat +whereas ++ komen het volgende overeen +agree as follows +hij he diff --git a/xml/source/snippets/snippetselection.xml b/xml/source/snippets/snippetselection.xml index 216f6aa..bd6ba61 100644 --- a/xml/source/snippets/snippetselection.xml +++ b/xml/source/snippets/snippetselection.xml @@ -1,30 +1,74 @@- diff --git a/xml/target/contract.fo b/xml/target/contract.fo index 941bfe8..04a8eb2 100644 --- a/xml/target/contract.fo +++ b/xml/target/contract.fo @@ -1,37 +1,466 @@ -- + + -introandscope projectoverview + introandscope projectoverview - - + + + -+ -parties + + +wa_companywants wa_companyhasasked wa_contractorcan wa_noemploymentintention + + ag_noemployment +ag_companyinstructs +ag_worktime +ag_ownrisk +ag_payment_single_engagement +ag_biggerscopewarning +ag_propertyrights +ag_retainrights +ag_nondisclosure +ag_responsibilities +ag_thirdparty +ag_liability +ag_provisions +ag_generaltermsandconditions +- parties -projectoverview ++ + + +parties ++ + +wa_contractorcan +wa_noemploymentintention ++ + ag_period +ag_noemployment +ag_companyinstructs +ag_ownrisk +ag_workinghours +ag_payment_fixed_term +ag_biggerscopewarning +ag_propertyrights +ag_retainrights +ag_nondisclosure +ag_responsibilities +ag_thirdparty +ag_liability +ag_provisions +ag_generaltermsandconditions +- WHEREAS:
+-
-
- AGREE AS FOLLOWS ++ <xsl:call-template name="getString"> + <xsl:with-param name="stringID" select="'contract_agree'"/> + </xsl:call-template> + -
-
@@ -259,22 +114,5 @@ - + xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" findingCode="???"> Penetration Test Report - - -- -- -- -- -- +diff --git a/xml/xslt/snippets.xslt b/xml/xslt/snippets.xslt new file mode 100644 index 0000000..355a927 --- /dev/null +++ b/xml/xslt/snippets.xslt @@ -0,0 +1,16 @@ + +
AND
-