3 ms·

The HTTP request does not have the users private keys. That never leaves your phone. The DB table looks like signal creates UUIDs to represent users and device

The HTTP request does not have the users private keys. That never leaves your phone. The DB table looks like signal creates UUIDs to represent users and devices. This isn’t really sensitive information but really just how you can see and revoke devices associated with your account. Maybe I’m misreading something tough. Do you have any reason to believe otherwise?

thrownoverboard 5y ago
Agreed that network compromise on the surface isn't a huge concern because of the Signal protocol itself. However, if the password (generated on each linked device) used for authentication is compromised, presumably it could be used to generate different keys altogether for an account. If the device password is compromised, then it seems feasible (but difficult) for some sort of attack be to be pulled off that could eventually lead to the compromise of messaging itself, or adding of another (shadow) linked device. The subpoena explicitly asks for: >Online Behaviors: Including device data, site interactions, and cookies if available >Activity Log: Including logs of click-stream data if available I would think device data would include things such as the number of devices associated with the phone number, which appear to be stored in the clear in the table, regardless of whether or not it is sensitive. Looking at the Device DynamoDB table, which is linked to the phone number, you'd also have things like the associated auth token + salt, GCM / APN IDs, public prekeys, etc. AWS DynamoDB is potentially going to have request logs for these requests as well, using the UUIDs, to associate finer-grained access timestamps. That may be useful for this case. It seems odd not to be using TLS within the VPC and storing these seemingly insensitive values encrypted within DynamoDB / SQS / etc. Doing so would ensure that compromise of the hosting provider is irrelevant. Why not terminate TLS on the Signal server itself, behind the load balancer? Why not use TLS for communications between the Signal server and the Redis cluster it uses? Why not encrypt phone numbers before storing them in DynamoDB?

thrownoverboard 5y ago

Agreed that network compromise on the surface isn't a huge concern because of the Signal protocol itself. However, if the password (generated on each linked device) used for authentication is compromised, presumably it could be used to generate different keys altogether for an account. If the device password is compromised, then it seems feasible (but difficult) for some sort of attack be to be pulled off that could eventually lead to the compromise of messaging itself, or adding of another (shadow) linked device. The subpoena explicitly asks for: >Online Behaviors: Including device data, site interactions, and cookies if available >Activity Log: Including logs of click-stream data if available I would think device data would include things such as the number of devices associated with the phone number, which appear to be stored in the clear in the table, regardless of whether or not it is sensitive. Looking at the Device DynamoDB table, which is linked to the phone number, you'd also have things like the associated auth token + salt, GCM / APN IDs, public prekeys, etc. AWS DynamoDB is potentially going to have request logs for these requests as well, using the UUIDs, to associate finer-grained access timestamps. That may be useful for this case. It seems odd not to be using TLS within the VPC and storing these seemingly insensitive values encrypted within DynamoDB / SQS / etc. Doing so would ensure that compromise of the hosting provider is irrelevant. Why not terminate TLS on the Signal server itself, behind the load balancer? Why not use TLS for communications between the Signal server and the Redis cluster it uses? Why not encrypt phone numbers before storing them in DynamoDB?