author_facet Checkoway, Stephen
Maskiewicz, Jacob
Garman, Christina
Fried, Joshua
Cohney, Shaanan
Green, Matthew
Heninger, Nadia
Weinmann, Ralf-Philipp
Rescorla, Eric
Shacham, Hovav
Checkoway, Stephen
Maskiewicz, Jacob
Garman, Christina
Fried, Joshua
Cohney, Shaanan
Green, Matthew
Heninger, Nadia
Weinmann, Ralf-Philipp
Rescorla, Eric
Shacham, Hovav
author Checkoway, Stephen
Maskiewicz, Jacob
Garman, Christina
Fried, Joshua
Cohney, Shaanan
Green, Matthew
Heninger, Nadia
Weinmann, Ralf-Philipp
Rescorla, Eric
Shacham, Hovav
spellingShingle Checkoway, Stephen
Maskiewicz, Jacob
Garman, Christina
Fried, Joshua
Cohney, Shaanan
Green, Matthew
Heninger, Nadia
Weinmann, Ralf-Philipp
Rescorla, Eric
Shacham, Hovav
Communications of the ACM
Where did I leave my keys? : lessons from the Juniper Dual EC incident
General Computer Science
author_sort checkoway, stephen
spelling Checkoway, Stephen Maskiewicz, Jacob Garman, Christina Fried, Joshua Cohney, Shaanan Green, Matthew Heninger, Nadia Weinmann, Ralf-Philipp Rescorla, Eric Shacham, Hovav 0001-0782 1557-7317 Association for Computing Machinery (ACM) General Computer Science http://dx.doi.org/10.1145/3266291 <jats:p>In December 2015, Juniper Networks announced multiple security vulnerabilities stemming from unauthorized code in ScreenOS, the operating system for their NetScreen Virtual Private Network (VPN) routers. The more sophisticated of these vulnerabilities was a passive VPN decryption capability, enabled by a change to one of the parameters used by the Dual Elliptic Curve (EC) pseudorandom number generator.</jats:p> <jats:p>In this paper, we described the results of a full independent analysis of the ScreenOS randomness and VPN key establishment protocol subsystems, which we carried out in response to this incident. While Dual EC is known to be insecure against an attacker who can choose the elliptic curve parameters, Juniper had claimed in 2013 that ScreenOS included countermeasures against this type of attack. We find that, contrary to Juniper's public statements, the ScreenOS VPN implementation has been vulnerable to passive exploitation by an attacker who selects the Dual EC curve point since 2008. This vulnerability arises due to flaws in Juniper's countermeasures as well as a cluster of changes that were all introduced concurrently with the inclusion of Dual EC in a single 2008 release. We demonstrate the vulnerability on a real NetScreen device by modifying the firmware to install our own parameters, and we show that it is possible to passively decrypt an individual VPN session in isolation without observing any other network traffic. This incident is an important example of how guidelines for random number generation, engineering, and validation can fail in practice. Additionally, it casts further doubt on the practicality of designing a safe "exceptional access" or "key escrow" scheme of the type contemplated by law enforcement agencies in the United States and elsewhere.</jats:p> lessons from the Juniper Dual EC incident Where did I leave my keys? : lessons from the Juniper Dual EC incident Communications of the ACM
doi_str_mv 10.1145/3266291
facet_avail Online
format ElectronicArticle
fullrecord blob:ai-49-aHR0cDovL2R4LmRvaS5vcmcvMTAuMTE0NS8zMjY2Mjkx
id ai-49-aHR0cDovL2R4LmRvaS5vcmcvMTAuMTE0NS8zMjY2Mjkx
institution DE-L229
DE-D275
DE-Bn3
DE-Brt1
DE-D161
DE-Gla1
DE-Zi4
DE-15
DE-Pl11
DE-Rs1
DE-105
DE-14
FID-BBI-DE-23
DE-Ch1
imprint Association for Computing Machinery (ACM), 2018
imprint_str_mv Association for Computing Machinery (ACM), 2018
issn 0001-0782
1557-7317
issn_str_mv 0001-0782
1557-7317
language English
mega_collection Association for Computing Machinery (ACM) (CrossRef)
match_str checkoway2018wheredidileavemykeyslessonsfromthejuniperdualecincidentlessonsfromthejuniperdualecincident
publishDateSort 2018
publisher Association for Computing Machinery (ACM)
recordtype ai
record_format ai
series Communications of the ACM
source_id 49
title_sub lessons from the Juniper Dual EC incident
title Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_unstemmed Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_full Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_fullStr Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_full_unstemmed Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_short Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_sort where did i leave my keys? : lessons from the juniper dual ec incident
topic General Computer Science
url http://dx.doi.org/10.1145/3266291
publishDate 2018
physical 148-155
description <jats:p>In December 2015, Juniper Networks announced multiple security vulnerabilities stemming from unauthorized code in ScreenOS, the operating system for their NetScreen Virtual Private Network (VPN) routers. The more sophisticated of these vulnerabilities was a passive VPN decryption capability, enabled by a change to one of the parameters used by the Dual Elliptic Curve (EC) pseudorandom number generator.</jats:p> <jats:p>In this paper, we described the results of a full independent analysis of the ScreenOS randomness and VPN key establishment protocol subsystems, which we carried out in response to this incident. While Dual EC is known to be insecure against an attacker who can choose the elliptic curve parameters, Juniper had claimed in 2013 that ScreenOS included countermeasures against this type of attack. We find that, contrary to Juniper's public statements, the ScreenOS VPN implementation has been vulnerable to passive exploitation by an attacker who selects the Dual EC curve point since 2008. This vulnerability arises due to flaws in Juniper's countermeasures as well as a cluster of changes that were all introduced concurrently with the inclusion of Dual EC in a single 2008 release. We demonstrate the vulnerability on a real NetScreen device by modifying the firmware to install our own parameters, and we show that it is possible to passively decrypt an individual VPN session in isolation without observing any other network traffic. This incident is an important example of how guidelines for random number generation, engineering, and validation can fail in practice. Additionally, it casts further doubt on the practicality of designing a safe "exceptional access" or "key escrow" scheme of the type contemplated by law enforcement agencies in the United States and elsewhere.</jats:p>
container_issue 11
container_start_page 148
container_title Communications of the ACM
container_volume 61
format_de105 Article, E-Article
format_de14 Article, E-Article
format_de15 Article, E-Article
format_de520 Article, E-Article
format_de540 Article, E-Article
format_dech1 Article, E-Article
format_ded117 Article, E-Article
format_degla1 E-Article
format_del152 Buch
format_del189 Article, E-Article
format_dezi4 Article
format_dezwi2 Article, E-Article
format_finc Article, E-Article
format_nrw Article, E-Article
_version_ 1792339811767418887
geogr_code not assigned
last_indexed 2024-03-01T15:54:02.505Z
geogr_code_person not assigned
openURL url_ver=Z39.88-2004&ctx_ver=Z39.88-2004&ctx_enc=info%3Aofi%2Fenc%3AUTF-8&rfr_id=info%3Asid%2Fvufind.svn.sourceforge.net%3Agenerator&rft.title=Where+did+I+leave+my+keys%3F+%3A+lessons+from+the+Juniper+Dual+EC+incident&rft.date=2018-10-26&genre=article&issn=1557-7317&volume=61&issue=11&spage=148&epage=155&pages=148-155&jtitle=Communications+of+the+ACM&atitle=Where+did+I+leave+my+keys%3F+%3A+lessons+from+the+Juniper+Dual+EC+incident&aulast=Shacham&aufirst=Hovav&rft_id=info%3Adoi%2F10.1145%2F3266291&rft.language%5B0%5D=eng
SOLR
_version_ 1792339811767418887
author Checkoway, Stephen, Maskiewicz, Jacob, Garman, Christina, Fried, Joshua, Cohney, Shaanan, Green, Matthew, Heninger, Nadia, Weinmann, Ralf-Philipp, Rescorla, Eric, Shacham, Hovav
author_facet Checkoway, Stephen, Maskiewicz, Jacob, Garman, Christina, Fried, Joshua, Cohney, Shaanan, Green, Matthew, Heninger, Nadia, Weinmann, Ralf-Philipp, Rescorla, Eric, Shacham, Hovav, Checkoway, Stephen, Maskiewicz, Jacob, Garman, Christina, Fried, Joshua, Cohney, Shaanan, Green, Matthew, Heninger, Nadia, Weinmann, Ralf-Philipp, Rescorla, Eric, Shacham, Hovav
author_sort checkoway, stephen
container_issue 11
container_start_page 148
container_title Communications of the ACM
container_volume 61
description <jats:p>In December 2015, Juniper Networks announced multiple security vulnerabilities stemming from unauthorized code in ScreenOS, the operating system for their NetScreen Virtual Private Network (VPN) routers. The more sophisticated of these vulnerabilities was a passive VPN decryption capability, enabled by a change to one of the parameters used by the Dual Elliptic Curve (EC) pseudorandom number generator.</jats:p> <jats:p>In this paper, we described the results of a full independent analysis of the ScreenOS randomness and VPN key establishment protocol subsystems, which we carried out in response to this incident. While Dual EC is known to be insecure against an attacker who can choose the elliptic curve parameters, Juniper had claimed in 2013 that ScreenOS included countermeasures against this type of attack. We find that, contrary to Juniper's public statements, the ScreenOS VPN implementation has been vulnerable to passive exploitation by an attacker who selects the Dual EC curve point since 2008. This vulnerability arises due to flaws in Juniper's countermeasures as well as a cluster of changes that were all introduced concurrently with the inclusion of Dual EC in a single 2008 release. We demonstrate the vulnerability on a real NetScreen device by modifying the firmware to install our own parameters, and we show that it is possible to passively decrypt an individual VPN session in isolation without observing any other network traffic. This incident is an important example of how guidelines for random number generation, engineering, and validation can fail in practice. Additionally, it casts further doubt on the practicality of designing a safe "exceptional access" or "key escrow" scheme of the type contemplated by law enforcement agencies in the United States and elsewhere.</jats:p>
doi_str_mv 10.1145/3266291
facet_avail Online
format ElectronicArticle
format_de105 Article, E-Article
format_de14 Article, E-Article
format_de15 Article, E-Article
format_de520 Article, E-Article
format_de540 Article, E-Article
format_dech1 Article, E-Article
format_ded117 Article, E-Article
format_degla1 E-Article
format_del152 Buch
format_del189 Article, E-Article
format_dezi4 Article
format_dezwi2 Article, E-Article
format_finc Article, E-Article
format_nrw Article, E-Article
geogr_code not assigned
geogr_code_person not assigned
id ai-49-aHR0cDovL2R4LmRvaS5vcmcvMTAuMTE0NS8zMjY2Mjkx
imprint Association for Computing Machinery (ACM), 2018
imprint_str_mv Association for Computing Machinery (ACM), 2018
institution DE-L229, DE-D275, DE-Bn3, DE-Brt1, DE-D161, DE-Gla1, DE-Zi4, DE-15, DE-Pl11, DE-Rs1, DE-105, DE-14, FID-BBI-DE-23, DE-Ch1
issn 0001-0782, 1557-7317
issn_str_mv 0001-0782, 1557-7317
language English
last_indexed 2024-03-01T15:54:02.505Z
match_str checkoway2018wheredidileavemykeyslessonsfromthejuniperdualecincidentlessonsfromthejuniperdualecincident
mega_collection Association for Computing Machinery (ACM) (CrossRef)
physical 148-155
publishDate 2018
publishDateSort 2018
publisher Association for Computing Machinery (ACM)
record_format ai
recordtype ai
series Communications of the ACM
source_id 49
spelling Checkoway, Stephen Maskiewicz, Jacob Garman, Christina Fried, Joshua Cohney, Shaanan Green, Matthew Heninger, Nadia Weinmann, Ralf-Philipp Rescorla, Eric Shacham, Hovav 0001-0782 1557-7317 Association for Computing Machinery (ACM) General Computer Science http://dx.doi.org/10.1145/3266291 <jats:p>In December 2015, Juniper Networks announced multiple security vulnerabilities stemming from unauthorized code in ScreenOS, the operating system for their NetScreen Virtual Private Network (VPN) routers. The more sophisticated of these vulnerabilities was a passive VPN decryption capability, enabled by a change to one of the parameters used by the Dual Elliptic Curve (EC) pseudorandom number generator.</jats:p> <jats:p>In this paper, we described the results of a full independent analysis of the ScreenOS randomness and VPN key establishment protocol subsystems, which we carried out in response to this incident. While Dual EC is known to be insecure against an attacker who can choose the elliptic curve parameters, Juniper had claimed in 2013 that ScreenOS included countermeasures against this type of attack. We find that, contrary to Juniper's public statements, the ScreenOS VPN implementation has been vulnerable to passive exploitation by an attacker who selects the Dual EC curve point since 2008. This vulnerability arises due to flaws in Juniper's countermeasures as well as a cluster of changes that were all introduced concurrently with the inclusion of Dual EC in a single 2008 release. We demonstrate the vulnerability on a real NetScreen device by modifying the firmware to install our own parameters, and we show that it is possible to passively decrypt an individual VPN session in isolation without observing any other network traffic. This incident is an important example of how guidelines for random number generation, engineering, and validation can fail in practice. Additionally, it casts further doubt on the practicality of designing a safe "exceptional access" or "key escrow" scheme of the type contemplated by law enforcement agencies in the United States and elsewhere.</jats:p> lessons from the Juniper Dual EC incident Where did I leave my keys? : lessons from the Juniper Dual EC incident Communications of the ACM
spellingShingle Checkoway, Stephen, Maskiewicz, Jacob, Garman, Christina, Fried, Joshua, Cohney, Shaanan, Green, Matthew, Heninger, Nadia, Weinmann, Ralf-Philipp, Rescorla, Eric, Shacham, Hovav, Communications of the ACM, Where did I leave my keys? : lessons from the Juniper Dual EC incident, General Computer Science
title Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_full Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_fullStr Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_full_unstemmed Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_short Where did I leave my keys? : lessons from the Juniper Dual EC incident
title_sort where did i leave my keys? : lessons from the juniper dual ec incident
title_sub lessons from the Juniper Dual EC incident
title_unstemmed Where did I leave my keys? : lessons from the Juniper Dual EC incident
topic General Computer Science
url http://dx.doi.org/10.1145/3266291