Open source software—software that is freely dis­trib­uted, along with its source code, so that copies, addi­tions, or mod­i­fi­ca­tions can be read­i­ly made —is “every­where,” to quote the 2023 Open Source Secu­ri­ty and Risk Analy­sis Report. Of the com­put­er pro­grams used by major indus­tries, 96% include open source soft­ware, and 76% of those pro­grams con­sists of open source soft­ware. But the per­cent­age of soft­ware pack­ages “con­tain­ing secu­ri­ty vul­ner­a­bil­i­ties remains trou­bling­ly high,” the report warned.

One con­cern is that “the soft­ware you’ve got­ten from what you believe to be a reli­able devel­op­er has some­how been com­pro­mised,” says Kelsey Mer­rill, a soft­ware engi­neer who received a mas­ter’s degree ear­li­er this year from MIT’s Depart­ment of Elec­tri­cal Engi­neer­ing and Com­put­er Sci­ence. “Sup­pose that some­where in the sup­ply chain, the soft­ware has been changed by an attack­er who has mali­cious intent.”

The risk of a secu­ri­ty breach of this sort is by no means abstract. In 2020, to take a noto­ri­ous exam­ple, the Texas com­pa­ny Solar­Winds made a soft­ware update to its wide­ly used pro­gram called Ori­on. Hack­ers broke into the sys­tem, insert­ing per­ni­cious code into the soft­ware before Solar­Winds shipped the lat­est ver­sion of Ori­on to more than 18,000 cus­tomers, includ­ing Microsoft, Intel, and rough­ly 100 oth­er com­pa­nies, as well as a dozen U.S. gov­ern­ment agencies—including the Depart­ments of State, Defense, Trea­sury, Com­merce, and Home­land Secu­ri­ty.

In this case, the prod­uct that was cor­rupt­ed came from a large com­mer­cial com­pa­ny, but laps­es may be even more like­ly to occur in the open source realm, Mer­rill says, “where peo­ple of vary­ing backgrounds—many of whom are hob­by­ists with­out any secu­ri­ty training—can pub­lish soft­ware that gets used around the world.”

She and three collaborators—her for­mer advi­sor Karen Sollins, a Prin­ci­pal Sci­en­tist at the MIT Com­put­er Sci­ence and Arti­fi­cial Intel­li­gence Lab­o­ra­to­ry; San­ti­a­go Tor­res-Arias, an assis­tant pro­fes­sor of com­put­er sci­ence at Pur­due Uni­ver­si­ty; and Zachary New­man, a for­mer MIT grad­u­ate stu­dent and cur­rent research sci­en­tist at Chain­guard Labs—have devel­oped a new sys­tem called Sper­an­za, which is aimed at reas­sur­ing soft­ware con­sumers that the prod­uct they are get­ting has not been tam­pered with and is com­ing direct­ly from a source they trust. The paper is pub­lished on the arX­iv preprint serv­er.

“What we have done,” explains Sollins, “is to devel­op, prove cor­rect, and demon­strate the via­bil­i­ty of an approach that allows the [soft­ware] main­tain­ers to remain anony­mous.” Pre­serv­ing anonymi­ty is obvi­ous­ly impor­tant, giv­en that almost everyone—software devel­op­ers included—value their con­fi­den­tial­i­ty. This new approach, Sollins adds, “simul­ta­ne­ous­ly allows [soft­ware] users to have con­fi­dence that the main­tain­ers are, in fact, legit­i­mate main­tain­ers and, fur­ther­more, that the code being down­loaded is, in fact, the cor­rect code of that main­tain­er.”

So how can users con­firm the gen­uine­ness of a soft­ware pack­age in order to guar­an­tee, as Mer­rill puts it, “that the main­tain­ers are who they say they are?” The clas­si­cal way of doing this, which was invent­ed more than 40 years ago, is by means of a dig­i­tal sig­na­ture, which is anal­o­gous to a hand­writ­ten signature—albeit with far greater built-in secu­ri­ty through the use of var­i­ous cryp­to­graph­ic tech­niques.

To car­ry out a dig­i­tal sig­na­ture, two “keys” are gen­er­at­ed at the same time—each of which is a num­ber, com­posed of zeros and ones, that is 256 dig­its long. One key is des­ig­nat­ed “pri­vate,” the oth­er “pub­lic,” but they con­sti­tute a pair that is math­e­mat­i­cal­ly linked.

A soft­ware devel­op­er can use their pri­vate key, along with the con­tents of the doc­u­ment or com­put­er pro­gram, to gen­er­ate a dig­i­tal sig­na­ture that is attached exclu­sive­ly to that doc­u­ment or pro­gram. A soft­ware user can then use the pub­lic key—as well as the devel­op­er’s sig­na­ture, plus the con­tents of the pack­age they downloaded—to ver­i­fy the pack­age’s authen­tic­i­ty.

Val­i­da­tion comes in the form of a yes or a no, a 1 or a zero. “Get­ting a 1 means that the authen­tic­i­ty has been assured,” Mer­rill explains. “The doc­u­ment is the same as when it was signed and is hence unchanged. A 0 means some­thing is amiss, and you may not want to rely on that doc­u­ment.”

Although this decades-old approach is tried-and-true in a sense, it is far from per­fect. One prob­lem, Mer­rill notes, “is that peo­ple are bad at man­ag­ing cryp­to­graph­ic keys, which con­sist of very long num­bers, in a way that is secure and pre­vents them from get­ting lost.” Peo­ple lose their pass­words all the time, Mer­rill says. “And if a soft­ware devel­op­er were to lose the pri­vate key and then con­tact a user say­ing, ‘Hey, I have a new key,’ how would you know who that real­ly is?”

To address those con­cerns, Sper­an­za is build­ing off of “Sigstore”—a sys­tem intro­duced last year to enhance the secu­ri­ty of the soft­ware sup­ply chain. Sig­store was devel­oped by New­man (who insti­gat­ed the Sper­an­za project) and Tor­res-Arias, along with John Speed Mey­ers of Chain­guard Labs. Sig­store auto­mates and stream­lines the dig­i­tal sign­ing process. Users no longer have to man­age long cryp­to­graph­ic keys but are instead issued ephemer­al keys (an approach called “key­less sign­ing”) that expire quickly—perhaps with­in a mat­ter of minutes—and there­fore don’t have to be stored.

A draw­back with Sig­store stems from the fact that it dis­pensed with long-last­ing pub­lic keys, so that soft­ware main­tain­ers instead have to iden­ti­fy themselves—through a pro­to­col called OpenID Con­nect (OIDC)—in a way that can be linked to their email address­es. That fea­ture, alone, may inhib­it the wide­spread adop­tion of Sig­store, and it served as the moti­vat­ing fac­tor behind—and the rai­son d’e­tre for—Speranza. “We take Sig­store’s basic infra­struc­ture and change it to pro­vide pri­va­cy guar­an­tees,” Mer­rill explains.

With Sper­an­za, pri­va­cy is achieved through an orig­i­nal idea that she and her col­lab­o­ra­tors call “iden­ti­ty co-com­mit­ments.” Here, in sim­ple terms, is how the idea works: A soft­ware devel­op­er’s iden­ti­ty, in the form of an email address, is con­vert­ed into a so-called “com­mit­ment” that con­sists of a big pseudo­ran­dom num­ber. (A pseudo­ran­dom num­ber does not meet the tech­ni­cal def­i­n­i­tion of “ran­dom” but, prac­ti­cal­ly speak­ing, is about as good as ran­dom.) Mean­while, anoth­er big pseudo­ran­dom number—the accom­pa­ny­ing com­mit­ment (or co-commitment)—is gen­er­at­ed that is asso­ci­at­ed with a soft­ware pack­age that this devel­op­er either cre­at­ed or was grant­ed per­mis­sion to mod­i­fy.

In order to demon­strate to a prospec­tive user of a par­tic­u­lar soft­ware pack­age as to who cre­at­ed this ver­sion of the pack­age and signed it, the autho­rized devel­op­er would pub­lish a proof that estab­lish­es an unequiv­o­cal link between the com­mit­ment that rep­re­sents their iden­ti­ty and the com­mit­ment attached to the soft­ware prod­uct. The proof that is car­ried out is of a spe­cial type, called a zero-knowl­edge proof, which is a way of show­ing, for instance, that two things have a com­mon bound, with­out divulging details as to what those things—such as the devel­op­er’s email address—actually are.

“Sper­an­za ensures that soft­ware comes from the cor­rect source with­out requir­ing devel­op­ers to reveal per­son­al infor­ma­tion like their email address­es,” com­ments Mari­na Moore, a Ph.D. can­di­date at the New York Uni­ver­si­ty Cen­ter for Cyber Secu­ri­ty. “It allows ver­i­fiers to see that the same devel­op­er signed a pack­age sev­er­al times with­out reveal­ing who the devel­op­er is or even oth­er pack­ages that they work on. This pro­vides a usabil­i­ty improve­ment over long-term sign­ing keys, and a pri­va­cy ben­e­fit over oth­er OIDC-based solu­tions like Sig­store.”

Marcela Mel­lara, a research sci­en­tist in the Secu­ri­ty and Pri­va­cy Research group at Intel Labs, agrees. “This approach has the advan­tage of allow­ing soft­ware con­sumers to auto­mat­i­cal­ly ver­i­fy that the pack­age they obtain from a Sper­an­za-enabled repos­i­to­ry orig­i­nat­ed from an expect­ed main­tain­er, and gain trust that the soft­ware they are using is authen­tic.”