Dell BSAFEซึ่งเดิมรู้จักกันในชื่อRSA BSAFEเป็น ไลบรารี การเข้ารหัสที่ได้รับ การตรวจสอบตามมาตรฐาน FIPS 140-2มีให้ใช้งานทั้งในภาษา CและJava BSAFE ถูกสร้างขึ้นครั้งแรกโดยRSA Securityซึ่งต่อมาถูกซื้อโดยEMCและ Dell เมื่อ Dell ขายธุรกิจ RSA ให้กับSymphony Technology Groupในปี 2020 Dell เลือกที่จะคงสายผลิตภัณฑ์ BSAFE ไว้^{[ 1 ] [ 2 ]} BSAFE เป็นหนึ่งในชุดเครื่องมือการเข้ารหัสที่ใช้กันทั่วไปมากที่สุดก่อนที่ สิทธิบัตร RSAจะหมดอายุในเดือนกันยายนปี 2000 นอกจากนี้ยังมีการใช้งานการเข้ารหัส RC xโดยการเข้ารหัสที่ใช้กันมากที่สุดคือRC4ตั้งแต่ปี 2004 ถึง 2013 ตัวสร้างเลขสุ่ม เริ่มต้น ในไลบรารีคือ มาตรฐาน RNG ที่ได้รับการอนุมัติ จาก NISTซึ่งเป็นที่ทราบกันดีว่าไม่ปลอดภัยมาตั้งแต่ปี 2006 เป็นอย่างน้อย โดยมีช่องโหว่การขโมยข้อมูล จาก สำนักงานความมั่นคงแห่งชาติของสหรัฐอเมริกา(NSA) ซึ่งเป็นส่วนหนึ่งของโครงการBullrun ที่เป็นความลับ ^{[ 3 ]}ในปี 2013 Reuters เปิดเผยว่า RSA ได้รับเงิน 10 ล้านดอลลาร์เพื่อตั้งค่าอัลกอริทึมที่ถูกบุกรุกเป็นตัวเลือกเริ่มต้น^{[ 3 ]}มาตรฐาน RNG ถูกถอนออกในภายหลังในปี 2014 และ RNG ถูกลบออกจาก BSAFE ตั้งแต่ปี 2015 เป็นต้นไป

ตั้งแต่ปี 2004 ถึง 2013 ตัวสร้างเลขสุ่มเทียมที่ปลอดภัยทางด้านการเข้ารหัส (CSPRNG) เริ่มต้นใน BSAFE คือDual_EC_DRBGซึ่งมีช่องโหว่ที่ถูกกล่าวหาว่ามาจากNSAนอกเหนือจากจะเป็น CSPRNG ที่มีอคติและทำงานช้า^{[ 4 ]}ชุมชนการเข้ารหัสตระหนักดีว่า Dual_EC_DRBG เป็น CSPRNG ที่แย่มากตั้งแต่ไม่นานหลังจากที่ข้อกำหนดถูกเผยแพร่ในปี 2005 และในปี 2007 ก็เป็นที่ชัดเจนว่า CSPRNG ดูเหมือนจะถูกออกแบบมาเพื่อมีช่องโหว่ที่ซ่อนอยู่สำหรับ NSA ซึ่ง NSA เท่านั้นที่สามารถใช้งานได้ผ่านกุญแจลับ^{[ 5 ]}ในปี 2007 บรูซ ชไนเออร์อธิบายช่องโหว่นี้ว่า "ชัดเจนเกินกว่าจะหลอกใครให้ใช้มันได้" ^{[ 5 ]}ช่องโหว่ดังกล่าวได้รับการยืนยันในการรั่วไหลของสโนว์เดนในปี 2013 และมีการกล่าวอ้างว่า NSA ได้จ่ายเงินให้ RSA Security จำนวน 10 ล้านดอลลาร์สหรัฐเพื่อใช้ Dual_EC_DRBG เป็นค่าเริ่มต้นในปี 2004 ^{[ 3 ]}แม้ว่า RSA Security จะปฏิเสธว่าพวกเขารู้เกี่ยวกับช่องโหว่ดังกล่าวในปี 2004 บทความของรอยเตอร์ที่เปิดเผยสัญญาลับมูลค่า 10 ล้านดอลลาร์สหรัฐเพื่อใช้ Dual_EC_DRBG อธิบายว่าข้อตกลงดังกล่าว "ดำเนินการโดยผู้นำทางธุรกิจมากกว่านักเทคโนโลยีล้วนๆ" ^{[ 3 ]} RSA Security ปฏิเสธที่จะอธิบายเหตุผลในการเลือกที่จะใช้ Dual_EC_DRBG ต่อไปแม้หลังจากที่พบข้อบกพร่องและช่องโหว่ที่อาจเกิดขึ้นในปี 2006 และ 2007 และปฏิเสธว่าจงใจใส่ช่องโหว่ดังกล่าว^{[ 6 ]}

แล้วทำไม RSA ถึงเลือก Dual_EC เป็นค่าเริ่มต้น? ผมก็สงสัยเหมือนกัน เพราะ Dual_EC ไม่เพียงแต่ช้าอย่างน่าขัน – ซึ่งส่งผลกระทบต่อประสิทธิภาพการทำงานอย่างแท้จริง – แต่ยังมีการพิสูจน์แล้วว่าเป็นตัวสร้างเลขสุ่มที่แย่มากตั้งแต่ปี 2006 และในปี 2007 เมื่อ Shumow และ Ferguson ยกประเด็นความเป็นไปได้ของช่องโหว่ในข้อกำหนด นักเข้ารหัสลับที่ฉลาดคนไหนก็ไม่กล้าเข้าใกล้สิ่งนี้ และที่สำคัญกว่านั้นคือ RSA จ้างนักเข้ารหัสลับที่มีชื่อเสียงหลายคน! เป็นไปได้ยากที่พวกเขาจะพลาดข่าวเกี่ยวกับ Dual_EC ไปทั้งหมด

เนื่องจากตัวสร้างเลขสุ่มที่มีความปลอดภัยทางด้านการเข้ารหัสมักเป็นพื้นฐานของการเข้ารหัส ข้อมูลจำนวนมากที่เข้ารหัสด้วย BSAFE จึงไม่ปลอดภัยจาก NSA โดยเฉพาะอย่างยิ่ง มีการแสดงให้เห็นว่าช่องโหว่ทำให้ SSL/ TLSสามารถถูกเจาะได้อย่างสมบูรณ์โดยฝ่ายที่มีกุญแจส่วนตัวของช่องโหว่ (เช่น NSA) ^{[ 5 ]}เนื่องจากรัฐบาลสหรัฐฯ และบริษัทในสหรัฐฯ ก็ใช้ BSAFE ที่มีช่องโหว่เช่นกัน NSA จึงอาจทำให้ข้อมูลของสหรัฐฯ ไม่ปลอดภัยมากขึ้น หากกุญแจลับของ NSA สำหรับช่องโหว่ถูกขโมยไป นอกจากนี้ยังสามารถหากุญแจลับได้โดยการแก้ปัญหาเส้นโค้งวงรี ของอัลกอริทึมเพียงครั้งเดียว ^{[ 5 ]} (การเจาะการเข้ารหัสเส้นโค้งวงรีเพียงครั้งเดียวถือว่าไม่น่าเป็นไปได้ด้วยคอมพิวเตอร์และอัลกอริทึมในปัจจุบัน แต่ความก้าวหน้าอาจเกิดขึ้นได้)

ในเดือนมิถุนายน พ.ศ. 2556 เอ็ดเวิร์ด สโนว์เดนเริ่มเปิดเผยเอกสารของ NSA ในเดือนพฤศจิกายน พ.ศ. 2556 RSA ได้เปลี่ยนค่าเริ่มต้นเป็น HMAC DRBG โดยใช้ SHA-256 เป็นตัวเลือกเริ่มต้น เดือนถัดมา รอยเตอร์ได้เผยแพร่รายงานโดยอ้างอิงจากการรั่วไหลของสโนว์เดน โดยระบุว่า RSA ได้รับเงิน 10 ล้านดอลลาร์สหรัฐ เพื่อตั้งค่า Dual_EC_DRBG เป็นค่าเริ่มต้น^{[ 3 ]}

ในเวอร์ชันต่อมาของ Crypto-C Micro Edition 4.1.2 (เมษายน 2559), Micro Edition Suite 4.1.5 (เมษายน 2559) และ Crypto-J 6.2 (มีนาคม 2558) นั้น Dual_EC_DRBG ถูกลบออกไปโดยสิ้นเชิง

"Extended Random" เป็นส่วนขยายที่เสนอสำหรับ โปรโตคอล Transport Layer Security (TLS) ซึ่งส่งให้IETF เพื่อการกำหนดมาตรฐาน โดยพนักงานของ NSA ^{[ 7 ]}แม้ว่าจะไม่เคยกลายเป็นมาตรฐานก็ตาม ส่วนขยายนี้จะไม่เป็นอันตรายหากใช้ร่วมกัน แต่เมื่อรวมกับ Dual_EC_DRBG จะทำให้ใช้ประโยชน์จากช่องโหว่ได้ง่ายขึ้น^{[ 8 ] [ 9 ]}

ก่อนหน้านี้ไม่ทราบว่าส่วนขยายนี้เปิดใช้งานในการใช้งานใด ๆ แต่ในเดือนธันวาคม 2017 พบว่ามีการเปิดใช้งานใน เครื่องพิมพ์ Canon บาง รุ่นที่ใช้ไลบรารี RSA BSAFE เนื่องจากหมายเลขส่วนขยายขัดแย้งกับส่วนหนึ่งของ TLS เวอร์ชัน 1.3 ^{[ 9 ]}

• Crypto-J เป็นไลบรารีการเข้ารหัส Java ในปี 1997 RSA Data Securityได้รับใบอนุญาตไลบรารี J/CRYPTO ของ Baltimore Technologies โดยมีแผนที่จะรวมเข้าเป็นส่วนหนึ่งของชุดเครื่องมือการเข้ารหัส JSAFE ใหม่^{[ 10 ]}และได้ออก JSAFE เวอร์ชันแรกในปีเดียวกัน^{[ 11 ]} JSAFE 1.0 ได้รับการนำเสนอใน นิตยสารByteฉบับเดือนมกราคม 1998 ^{[ 12 ]}
• Cert-J เป็นไลบรารีซอฟต์แวร์API โครงสร้างพื้นฐานกุญแจสาธารณะ (Public Key Infrastructure) ที่เขียนด้วย ภาษา Javaประกอบด้วยส่วนสนับสนุนด้านการเข้ารหัสที่จำเป็นสำหรับการสร้างคำขอใบรับรอง การสร้างและลงนามในใบรับรองดิจิทัลและการสร้างและแจกจ่ายรายการเพิกถอนใบรับรองตั้งแต่ Cert-J เวอร์ชัน 6.2.4 เป็นต้นไป API ทั้งหมดได้ถูกยกเลิกการใช้งานแล้ว และแทนที่ด้วยฟังก์ชันการทำงานที่คล้ายกันซึ่งมีให้ใน BSAFE Crypto-J JCE API
• BSAFE Crypto-C Micro Edition (Crypto-C ME) เปิดตัวครั้งแรกในเดือนมิถุนายน พ.ศ. 2544 ภายใต้ชื่อ "RSA BSAFE Wireless Core 1.0" โดยเวอร์ชันแรกนั้นรองรับระบบปฏิบัติการ Microsoft Windows , EPOC , Linux , SolarisและPalm OS
• BSAFE Micro Edition Suite เป็นSDK สำหรับการเข้ารหัสลับ ในภาษา C BSAFE Micro Edition Suite ได้รับการประกาศครั้งแรกในเดือนกุมภาพันธ์ พ.ศ. 2545 ^{[ 13 ]}โดยเป็นการรวม BSAFE SSL-C Micro Edition, BSAFE Cert-C Micro Edition และ BSAFE Crypto-C Micro Edition เข้าด้วยกัน ทั้ง SSL-C Micro Edition และ Cert-C Micro Edition สิ้นสุดการสนับสนุนในเดือนกันยายน พ.ศ. 2557 ในขณะที่ Micro Edition Suite ยังคงได้รับการสนับสนุนต่อไป โดยมี Crypto-C Micro Edition เป็นผู้ให้บริการการเข้ารหัสลับที่ได้รับการตรวจสอบFIPS
• SSL-C เป็น ชุดเครื่องมือ SSLในชุด BSAFE เดิมทีเขียนโดย Eric A. Young และ Tim J. Hudson โดยแยกออกมาจากไลบรารีแบบเปิดSSLeayที่พวกเขาพัฒนาขึ้นก่อนเข้าร่วม RSA ^{[ 14 ] [ 15 ]} SSL-C สิ้นสุดอายุการใช้งานในเดือนธันวาคม 2016
• SSL-J เป็นชุดเครื่องมือ Java ที่ใช้TLS SSL-J เปิดตัวเป็นส่วนหนึ่งของผลิตภัณฑ์เริ่มต้นของ RSA JSAFE ในปี 1997 ^{[ 16 ]} Crypto-J เป็นผู้ให้บริการการเข้ารหัสลับเริ่มต้นของ SSL-J

เมื่อวันที่ 25 พฤศจิกายน 2015 RSA ได้ประกาศวันสิ้นสุดการสนับสนุน (EOL) สำหรับ BSAFE ^{[ 17 ]}วันสิ้นสุดการสนับสนุนหลัก (EOPS) จะสิ้นสุดในวันที่ 31 มกราคม 2017 และวันสิ้นสุดการสนับสนุนเพิ่มเติม (EOXS) เดิมกำหนดไว้เป็นวันที่ 31 มกราคม 2019 ต่อมา RSA ได้ขยายวันดังกล่าวออกไปอีกสำหรับบางเวอร์ชันจนถึงวันที่ 31 มกราคม 2022 ^{[ 18 ]}ในระหว่างการสนับสนุนเพิ่มเติม แม้ว่านโยบายการสนับสนุนจะระบุว่าจะมีเพียงปัญหาที่ร้ายแรงที่สุดเท่านั้นที่จะได้รับการแก้ไข แต่ก็มีการออกเวอร์ชันใหม่ที่มีการแก้ไขข้อบกพร่อง การแก้ไขด้านความปลอดภัย และอัลกอริทึมใหม่^{[ 19 ]}

เมื่อวันที่ 12 ธันวาคม 2020 Dell ประกาศการเปลี่ยนแปลงการตัดสินใจก่อนหน้านี้ของ RSA ซึ่งอนุญาตให้มีการสนับสนุนผลิตภัณฑ์ BSAFE ต่อไปหลังจากเดือนมกราคม 2022 รวมถึงความเป็นไปได้ที่จะได้รับใบอนุญาตใหม่ในเร็วๆ นี้ Dell ยังประกาศด้วยว่าจะเปลี่ยนชื่อชุดเครื่องมือเป็นDell BSAFE ^{[ 20 ]}

• หน้าสนับสนุน BSAFE Cert-J
• หน้าสนับสนุน BSAFE Crypto-J
• หน้าสนับสนุน BSAFE SSL-J
• หน้าสนับสนุน BSAFE Crypto-C Micro Edition
• หน้าสนับสนุนชุดโปรแกรม BSAFE Micro Edition