[SERVER-40516] Ban single-valued BSON types in FLE Created: 06/Apr/19  Updated: 29/Oct/23  Resolved: 03/May/19

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 4.1.11

Type: Improvement Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Ted Tuckman
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-41264 Mongocryptd is willing to mark single... Closed
Backwards Compatibility: Fully Compatible
Sprint: Query 2019-05-06, Query 2019-05-20
Participants:

 Description   

When a BSON value of any type is encrypted, its value is hidden but its type is deliberately exposed as plaintext. This scheme hides BSON values of type String, Double, etc., but the following BSON types can have only one value:

  • 0x06 Undefined (deprecated)
  • 0x0A Null
  • 0xFF Min key
  • 0x7F Max key

Therefore, encrypting a value of a single-valued type leaves its value exposed, since its value is implied by its type. A JSON schema that specifies an encrypted field of one of these types is invalid, and mongocryptd must return an error for such a schema.



 Comments   
Comment by Githook User [ 03/May/19 ]

Author:

{'name': 'Ted Tuckman', 'username': 'TedTuckman', 'email': 'ted.tuckman@mongodb.com'}

Message: SERVER-40516 Ban single-valued BSON types in encrypt object
Branch: master
https://github.com/mongodb/mongo/commit/117a422917ff9110a4ae2b3023e7dc88fb491567

Comment by A. Jesse Jiryu Davis [ 09/Apr/19 ]

Could be. If they're encrypted with nondeterministic encryption then they're secure, otherwise you can at least see that two documents have the same value for a field (without knowing whether that value is true or false), and you can usually guess from the distribution which is true or false. Nondeterministic encryption is best for any low-cardinality field: an integer field that in practice has only 3 fields is nearly as vulnerable as a boolean if you use deterministic encryption. I think that the single-valued fields are special, though.

Comment by Kevin Pulo [ 09/Apr/19 ]

Is there a similar argument to be made for BSON booleans, which can only have two possible values (\x00 and \x01)?

Comment by A. Jesse Jiryu Davis [ 08/Apr/19 ]

After discussion with behackett, I have an additional justification for banning these 4 types.

Our proposed solution to SERVER-40477 is to require users to specify the type of each encrypted field in the JSON Schema and use only that type when inserting, updating, or querying values of that field. So if a user provides a Null value and wants it auto-encrypted, this means the value is destined for a field that is specified as Null type in the JSON schema, and all values for this field are Null. This is not only insecure but also useless. It seems like such a schema is surely a mistake.

Explicit encryption without a JSON Schema is different from auto-encryption. A user could store encrypted values of several types in the same field using explicit encryption. In this case we should still ban encryption of single-valued types because encrypting these values does not hide them.

Generated at Thu Feb 08 04:55:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.