3 ms·

Thanks for your reply. I'm aware of what the FBI was asking for (Val Caproni is no longer there, FYI) four years ago. My reporting before I founded recent.io wa

by declan 12y ago

Thanks for your reply. I'm aware of what the FBI was asking for (Val Caproni is no longer there, FYI) four years ago. My reporting before I founded recent.io was the first to disclose some elements of the bureau's demands and strategy, in fact. You're right that it's unreasonable to place blind trust in a closed encryption system, even Apple's, that we're unable to review or audit. Even if their intentions are pure, it could be poorly implemented. But my point is simply this: there is no U.S. law mandating key escrow for Apple, Google, Microsoft, etc. One was proposed in the 1990s. It didn't pass. One was proposed in the Going Dark era 4-5 years ago. It didn't pass. One is being quasi-proposed now. It hasn't passed. I actually think I'll agree with you on a lot of issues based on your post above -- but it is nevertheless a conspiracy theory to claim that Silicon Valley companies somehow engage in key escrow for the NSA or that there is a legal requirement for them to do so. As I said before, if you claim otherwise, URL, please. >NSA currently requires companies (like Microsoft, Apple) to provide encryption keys corresponding to devices PS: ^^^ I'm still waiting for the link that backs up this claim too.

xnull2guest 12y ago
AFAIK there is no explicit law requiring every company that sells cryptography (in the general case, i.e. not as a service provider) to provide key escrow. However, this is not to discount law in praxis, how CALEA is interpreted and enforced, the history of key escrow, current technology considerations, known and suspected escrow mechanisms, and pressures exerted by federal law enforcement (e.g. the removal of effective crypto from Skype when it captured its market), and how all of this hangs together. My (reasonably, educated and technically informed :p) suspicion is that companies at a certain size, federal agents will come to your company and make demands for data, which you must comply with and slowly as you are compelled by law to give keys and data on a regular basis it becomes the best thing for your business to install automatic escrow mechanisms. It is my assertion that law enforcement interprets laws that read as "...unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication" as enough to force companies to create escrow mechanisms. I would argue some of this story played out very publicly with Google. Another great example here would be the NSL of Lavabit - how they asked for far more than was legally obligated and the forcefulness and non-public nature of the demands made it impossible to put forward a reasonable defense. To summarize it is apparent to me that the difference in our perspectives is whether a specific law (another being proposed again now, as you point out) is required in the current climate of practice of law, along with the leverage and the compliance requirements that exist inside it, for key escrow to be 'required of companies'. I come down on the side of 'no'. I believe they have what they need now to get escrow. Maybe this Apple and Google thing will clarify it. But somehow I doubt it. Prediction: no explicit law on key escrow will be passed (it would be entirely too harmful for US exports) but it will continue to be practiced.
- xnull2guest 12y ago
  Here are some interesting links. HP obtained a patented backdoor system in 2008 (filed mid 2000 and approved around the start of 2001). https://www.google.com/patents/EP1059578A2 https://www.google.com/patents/EP1059578A2 Certicom (the same company DUAL_EC was filed under) has a new key escrow system patented. https://www.google.com/patents/EP2637350A2 https://www.google.com/patents/EP2637350A2 Key escrow system filed in 2004 and published in 2011: https://www.google.com/patents/US8015597 https://www.google.com/patents/US8015597 2008-2012 stateless key escrow patent: https://www.google.com/patents/US8315395 https://www.google.com/patents/US8315395 "Automatic recovery of TPM keys" - Lenovo https://www.google.com/patents/US8290164 https://www.google.com/patents/US8290164 Oops, here's a Microsoft "cloud storage" key escrow system from 2011-2012. "Some of the files stored on the network server may be sensitive or confidential. The user may wish to restrict access to those files. The files may then be encrypted or otherwise protected with a password or other key. The user may not trust the network server to store the key, and may thus desire to retain sole possession of the key. Such users, however, often lose (or forget) their passwords or keys. Moreover, other third party users may legitimately require access to the stored, encrypted files." "FIG. 3 illustrates a flowchart of an example method for providing third party data access to a user's encrypted data according to a predefined policy." "In some cases, however, while the data storage system is not able to decrypt the user's data, it may be necessary for an outside entity (e.g. a governmental entity) to access the user's data." "In cases where the encrypted data is a cryptographic key, that key may be stored as a plurality of shares. The shares are mathematical transformations of the user's private key, and each share is provided to one of the verified third parties. Each verified third party publishes his or her own public keys, and encrypts his or her share of the encrypted key using their published public key. The verified third party shares encrypted according to the third partys' public keys are then stored in the data storage system. Because the shares are encrypted according to the verified third parties' public/private key pair, the data storage system is prevented from accessing the encrypted shares, and is further prevented from accessing the user's data." "In some cases, the user's data may comprise, at least in part, a cryptographic key. The user's data, including the key, may be stored in multiple different shares." Encrypted data AND keys! The patent examiner cited "The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption" when doing his examination. https://www.google.com/patents/US20120321086 https://www.google.com/patents/US20120321086 http://academiccommons.columbia.edu/catalog/ac:127127 http://academiccommons.columbia.edu/catalog/ac:127127 Some Raytheon for good measure. A bit older, but certainly Bush era. https://www.google.com/patents/US7269261 https://www.google.com/patents/US7269261 Motorola [1]. Certicom [2]. Honeywell [3]. Motorola [4]. Deutsche Telekom Ag [5]. IBM [6]. Apple [7]. ‎Fujitsu [8]. Red hat [9]. F-Secure [10]. Sony [11]. Seagate [12]. Dell [13]. Sprint [14]. Nokia [15]. Gemalto [16]. Intel [17]. Samsung [18]. Symantec [19]. Sun Microsystems [20]. Toshiba [21]. Cinea [22]. General Dynamics [23]. Citicorp [24]. Siemens [25]. Ericsson [26]. VMWare [27]. Facebook [28]. HP [29]. Cisco [30]. Liquid Machines [31]. GIC [32]. Microsoft [33]. Novell [34]. And of course the US patent system has a classification for key escrow systems: 380/286. http://www.uspto.gov/web/patents/classification/uspc380/defs380.htm#C380S286000 http://www.uspto.gov/web/patents/classification/uspc380/defs... [1] https://www.google.com/patents/US7116786 https://www.google.com/patents/US7116786 [2] https://www.google.com/patents/US8688998 https://www.google.com/patents/US8688998 [3] https://www.google.com/patents/US20070140496 https://www.google.com/patents/US20070140496 [4] https://www.google.com/patents/US5241597 https://www.google.com/patents/US5241597 [5] https://www.google.com/patents/US7162037 https://www.google.com/patents/US7162037 [6] https://www.google.com/patents/US8195959 https://www.google.com/patents/US8195959 & https://www.google.com/patents/US7856664 https://www.google.com/patents/US7856664 & https://www.google.com/patents/US7873170 https://www.google.com/patents/US7873170 [7] https://www.google.com/patents/US20090319769 https://www.google.com/patents/US20090319769 [8] https://www.google.com/patents/US6754349 https://www.google.com/patents/US6754349 & https://www.google.com/patents/US8055911 https://www.google.com/patents/US8055911 & https://www.google.com/patents/US7752318 https://www.google.com/patents/US7752318 [9] https://www.google.com/patents/US8144876 https://www.google.com/patents/US8144876 & https://www.google.com/patents/US8494169 https://www.google.com/patents/US8494169 & https://www.google.com/patents/US20070280483 https://www.google.com/patents/US20070280483 [10] https://www.google.com/patents/US8824682 https://www.google.com/patents/US8824682 [11] https://www.google.com/patents/US7672458 https://www.google.com/patents/US7672458 [12] https://www.google.com/patents/US7899186 https://www.google.com/patents/US7899186 [13] https://www.google.com/patents/US20090080663 https://www.google.com/patents/US20090080663 [14] https://www.google.com/patents/US7869602 https://www.google.com/patents/US7869602 [15] https://www.google.com/patents/US8107623 https://www.google.com/patents/US8107623 [16] https://www.google.com/patents/US8074076 https://www.google.com/patents/US8074076 [17] https://www.google.com/patents/US6950523 https://www.google.com/patents/US6950523 [18] https://www.google.com/patents/US8315386 https://www.google.com/patents/US8315386 & https://www.google.com/patents/US20070172069 https://www.google.com/patents/US20070172069 & https://www.google.com/patents/US7492895 https://www.google.com/patents/US7492895 [19] https://www.google.com/patents/US8397281 https://www.google.com/patents/US8397281 [20] https://www.google.com/patents/US7050589 https://www.google.com/patents/US7050589 & https://www.google.com/patents/US7660423 https://www.google.com/patents/US7660423 & https://www.google.com/patents/US20100142713 https://www.google.com/patents/US20100142713 [21] https://www.google.com/patents/US8099609 https://www.google.com/patents/US8099609 [22] https://www.google.com/patents/US7277544 https://www.google.com/patents/US7277544 [23] https://www.google.com/patents/US20070195960 https://www.google.com/patents/US20070195960 [24] https://www.google.com/patents/US6970836 https://www.google.com/patents/US6970836 [25] https://www.google.com/patents/US7313697 https://www.google.com/patents/US7313697 [26] https://www.google.com/patents/US20080152151 https://www.google.com/patents/US20080152151 [27] https://www.google.com/patents/US8234518 https://www.google.com/patents/US8234518 [28] https://www.google.com/patents/US8490166 https://www.google.com/patents/US8490166 [29] https://www.google.com/patents/US6577735 https://www.google.com/patents/US6577735 [30] https://www.google.com/patents/US8631227 https://www.google.com/patents/US8631227 [31] https://www.google.com/patents/US7796760 https://www.google.com/patents/US7796760 [32] https://www.google.com/patents/US20040052380 https://www.google.com/patents/US20040052380 [33] https://www.google.com/patents/US20070003065 https://www.google.com/patents/US20070003065 [34] https://www.google.com/patents/US8098828 https://www.google.com/patents/US8098828

by declan 12y ago

xnull2guest 12y ago

AFAIK there is no explicit law requiring every company that sells cryptography (in the general case, i.e. not as a service provider) to provide key escrow. However, this is not to discount law in praxis, how CALEA is interpreted and enforced, the history of key escrow, current technology considerations, known and suspected escrow mechanisms, and pressures exerted by federal law enforcement (e.g. the removal of effective crypto from Skype when it captured its market), and how all of this hangs together. My (reasonably, educated and technically informed :p) suspicion is that companies at a certain size, federal agents will come to your company and make demands for data, which you must comply with and slowly as you are compelled by law to give keys and data on a regular basis it becomes the best thing for your business to install automatic escrow mechanisms. It is my assertion that law enforcement interprets laws that read as "...unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication" as enough to force companies to create escrow mechanisms. I would argue some of this story played out very publicly with Google. Another great example here would be the NSL of Lavabit - how they asked for far more than was legally obligated and the forcefulness and non-public nature of the demands made it impossible to put forward a reasonable defense. To summarize it is apparent to me that the difference in our perspectives is whether a specific law (another being proposed again now, as you point out) is required in the current climate of practice of law, along with the leverage and the compliance requirements that exist inside it, for key escrow to be 'required of companies'. I come down on the side of 'no'. I believe they have what they need now to get escrow. Maybe this Apple and Google thing will clarify it. But somehow I doubt it. Prediction: no explicit law on key escrow will be passed (it would be entirely too harmful for US exports) but it will continue to be practiced.

xnull2guest 12y ago
Here are some interesting links. HP obtained a patented backdoor system in 2008 (filed mid 2000 and approved around the start of 2001). https://www.google.com/patents/EP1059578A2 https://www.google.com/patents/EP1059578A2 Certicom (the same company DUAL_EC was filed under) has a new key escrow system patented. https://www.google.com/patents/EP2637350A2 https://www.google.com/patents/EP2637350A2 Key escrow system filed in 2004 and published in 2011: https://www.google.com/patents/US8015597 https://www.google.com/patents/US8015597 2008-2012 stateless key escrow patent: https://www.google.com/patents/US8315395 https://www.google.com/patents/US8315395 "Automatic recovery of TPM keys" - Lenovo https://www.google.com/patents/US8290164 https://www.google.com/patents/US8290164 Oops, here's a Microsoft "cloud storage" key escrow system from 2011-2012. "Some of the files stored on the network server may be sensitive or confidential. The user may wish to restrict access to those files. The files may then be encrypted or otherwise protected with a password or other key. The user may not trust the network server to store the key, and may thus desire to retain sole possession of the key. Such users, however, often lose (or forget) their passwords or keys. Moreover, other third party users may legitimately require access to the stored, encrypted files." "FIG. 3 illustrates a flowchart of an example method for providing third party data access to a user's encrypted data according to a predefined policy." "In some cases, however, while the data storage system is not able to decrypt the user's data, it may be necessary for an outside entity (e.g. a governmental entity) to access the user's data." "In cases where the encrypted data is a cryptographic key, that key may be stored as a plurality of shares. The shares are mathematical transformations of the user's private key, and each share is provided to one of the verified third parties. Each verified third party publishes his or her own public keys, and encrypts his or her share of the encrypted key using their published public key. The verified third party shares encrypted according to the third partys' public keys are then stored in the data storage system. Because the shares are encrypted according to the verified third parties' public/private key pair, the data storage system is prevented from accessing the encrypted shares, and is further prevented from accessing the user's data." "In some cases, the user's data may comprise, at least in part, a cryptographic key. The user's data, including the key, may be stored in multiple different shares." Encrypted data AND keys! The patent examiner cited "The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption" when doing his examination. https://www.google.com/patents/US20120321086 https://www.google.com/patents/US20120321086 http://academiccommons.columbia.edu/catalog/ac:127127 http://academiccommons.columbia.edu/catalog/ac:127127 Some Raytheon for good measure. A bit older, but certainly Bush era. https://www.google.com/patents/US7269261 https://www.google.com/patents/US7269261 Motorola [1]. Certicom [2]. Honeywell [3]. Motorola [4]. Deutsche Telekom Ag [5]. IBM [6]. Apple [7]. ‎Fujitsu [8]. Red hat [9]. F-Secure [10]. Sony [11]. Seagate [12]. Dell [13]. Sprint [14]. Nokia [15]. Gemalto [16]. Intel [17]. Samsung [18]. Symantec [19]. Sun Microsystems [20]. Toshiba [21]. Cinea [22]. General Dynamics [23]. Citicorp [24]. Siemens [25]. Ericsson [26]. VMWare [27]. Facebook [28]. HP [29]. Cisco [30]. Liquid Machines [31]. GIC [32]. Microsoft [33]. Novell [34]. And of course the US patent system has a classification for key escrow systems: 380/286. http://www.uspto.gov/web/patents/classification/uspc380/defs380.htm#C380S286000 http://www.uspto.gov/web/patents/classification/uspc380/defs... [1] https://www.google.com/patents/US7116786 https://www.google.com/patents/US7116786 [2] https://www.google.com/patents/US8688998 https://www.google.com/patents/US8688998 [3] https://www.google.com/patents/US20070140496 https://www.google.com/patents/US20070140496 [4] https://www.google.com/patents/US5241597 https://www.google.com/patents/US5241597 [5] https://www.google.com/patents/US7162037 https://www.google.com/patents/US7162037 [6] https://www.google.com/patents/US8195959 https://www.google.com/patents/US8195959 & https://www.google.com/patents/US7856664 https://www.google.com/patents/US7856664 & https://www.google.com/patents/US7873170 https://www.google.com/patents/US7873170 [7] https://www.google.com/patents/US20090319769 https://www.google.com/patents/US20090319769 [8] https://www.google.com/patents/US6754349 https://www.google.com/patents/US6754349 & https://www.google.com/patents/US8055911 https://www.google.com/patents/US8055911 & https://www.google.com/patents/US7752318 https://www.google.com/patents/US7752318 [9] https://www.google.com/patents/US8144876 https://www.google.com/patents/US8144876 & https://www.google.com/patents/US8494169 https://www.google.com/patents/US8494169 & https://www.google.com/patents/US20070280483 https://www.google.com/patents/US20070280483 [10] https://www.google.com/patents/US8824682 https://www.google.com/patents/US8824682 [11] https://www.google.com/patents/US7672458 https://www.google.com/patents/US7672458 [12] https://www.google.com/patents/US7899186 https://www.google.com/patents/US7899186 [13] https://www.google.com/patents/US20090080663 https://www.google.com/patents/US20090080663 [14] https://www.google.com/patents/US7869602 https://www.google.com/patents/US7869602 [15] https://www.google.com/patents/US8107623 https://www.google.com/patents/US8107623 [16] https://www.google.com/patents/US8074076 https://www.google.com/patents/US8074076 [17] https://www.google.com/patents/US6950523 https://www.google.com/patents/US6950523 [18] https://www.google.com/patents/US8315386 https://www.google.com/patents/US8315386 & https://www.google.com/patents/US20070172069 https://www.google.com/patents/US20070172069 & https://www.google.com/patents/US7492895 https://www.google.com/patents/US7492895 [19] https://www.google.com/patents/US8397281 https://www.google.com/patents/US8397281 [20] https://www.google.com/patents/US7050589 https://www.google.com/patents/US7050589 & https://www.google.com/patents/US7660423 https://www.google.com/patents/US7660423 & https://www.google.com/patents/US20100142713 https://www.google.com/patents/US20100142713 [21] https://www.google.com/patents/US8099609 https://www.google.com/patents/US8099609 [22] https://www.google.com/patents/US7277544 https://www.google.com/patents/US7277544 [23] https://www.google.com/patents/US20070195960 https://www.google.com/patents/US20070195960 [24] https://www.google.com/patents/US6970836 https://www.google.com/patents/US6970836 [25] https://www.google.com/patents/US7313697 https://www.google.com/patents/US7313697 [26] https://www.google.com/patents/US20080152151 https://www.google.com/patents/US20080152151 [27] https://www.google.com/patents/US8234518 https://www.google.com/patents/US8234518 [28] https://www.google.com/patents/US8490166 https://www.google.com/patents/US8490166 [29] https://www.google.com/patents/US6577735 https://www.google.com/patents/US6577735 [30] https://www.google.com/patents/US8631227 https://www.google.com/patents/US8631227 [31] https://www.google.com/patents/US7796760 https://www.google.com/patents/US7796760 [32] https://www.google.com/patents/US20040052380 https://www.google.com/patents/US20040052380 [33] https://www.google.com/patents/US20070003065 https://www.google.com/patents/US20070003065 [34] https://www.google.com/patents/US8098828 https://www.google.com/patents/US8098828