{
	"id": "ab66d265-4528-4f17-8731-a2317169310c",
	"created_at": "2026-04-06T00:19:11.215264Z",
	"updated_at": "2026-04-10T13:11:36.086559Z",
	"deleted_at": null,
	"sha1_hash": "80abf336354d66090bb49b7efb48238074aae979",
	"title": "Ungilded Secrets: A New Paradigm for Key Security",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 174596,
	"plain_text": "Ungilded Secrets: A New Paradigm for Key Security\r\nBy Tal Be'ery\r\nPublished: 2021-01-25 · Archived: 2026-04-05 18:44:57 UTC\r\nTLDR: SUNBURST attackers recently used stolen private keys to compromise several high profile targets\r\nin the US. To significantly reduce the chances of this happening again, we suggest a radical approach based\r\non the cryptographic technology and security architecture that power our cryptocurrency wallet.\r\nRussian Intelligence hackers recently pulled off a major cyberattack on the US. What is now known as the\r\nSUNBURST attack compromised the computer networks of several US government agencies and leading IT and\r\nsecurity companies, including Microsoft and FireEye. \r\nAs authorities come to terms with the attack and learn of its true extent, most of the attention continues to focus on\r\nthe initial access vector, a supply chain attack on a leading IT vendor. However, we believe the attackers’ modus\r\noperandi of abusing golden secrets also needs to be scrutinized. \r\nGolden secrets are at the heart of most current authentication systems. These long-lasting secrets are used to\r\ncryptographically secure the issuance of shorter-term access tokens and protect their integrity. Consequently, they\r\nare also the most lucrative target for attackers. When a golden secret is captured, it allows attackers to issue golden\r\naccess tokens in an offline manner to take full control over their victims’ environment.\r\nIn this post, we’ll present a novel solution based on the same advanced cryptographic technology and security\r\narchitecture used in our cryptocurrency wallet, which we believe can substantially improve organizations’ ability\r\nto defend against such attacks.  \r\nSAML in SUNBURST\r\nThe SUNBURST attackers were initially able to enter their victims’ environments by infecting the software\r\nupdates of a widely used IT product called SolarWinds Orion (which is why this attack is named “SUNBURST”). \r\nOnce attackers were inside, their goal was to gain access to the authentication system’s golden secrets, mainly (but\r\nnot limited to) the SAML private key.\r\nSAML tokens can be likened to a permit, such as a driver’s license. When someone wants to obtain a driver’s\r\nlicense, they must visit the Department of Motor Vehicles (DMV) once to present the relevant papers (e.g., photo\r\nID and driving test results) and get a permit. \r\nThe permit details the individual’s identity and contains authorizations (i.e., to drive a certain type of vehicle).\r\nThis permit can be verified by multiple other parties (e.g., policemen) by checking the security measures\r\nembodied within.\r\nhttps://zengo.com/ungilded-secrets-a-new-paradigm-for-key-security/\r\nPage 1 of 5\n\nDriver license: contains driver’s authentication (name) and authorization (class D) information;\r\nsecurity measures embodied within the permit. (source: mn.gov )\r\nSimilarly, SAML tokens are issued by Identity Providers (IdP) within an organization (e.g., Microsoft ADFS).\r\nUsers authenticate once (in a while) to the IdP by showing their credentials: usernames, passwords, and Multi-Factor Authentication (MFA) and get a SAML token in return, signed by the IdP private key. \r\nThe SAML token details the person’s identity and authorization level (e.g., admin or regular user). When users\r\nwish to connect to multiple Service Providers (SPs), either on cloud or on-premises, they present their SAML\r\ntoken to the relevant SP. The SP verifies the token by validating the signature using the public key.\r\nOne critical difference between a SAML token and a driver’s license is that a SAML token is not a “photo ID.”\r\nThere is no way for the SPs to make sure the holder is the same person as the SAML token claims. SPs can only\r\nverify the token is signed correctly.\r\nBy stealing the SAML private key, the attackers could create their own tokens offline (i.e., without interacting\r\nwith any of the victims’ systems, thus leaving no traces in audit logs). They could also masquerade as any user\r\nwith different access privileges and totally bypass Multi-Factor Authentication (MFA), thus gaining\r\nunlimited access to all systems.\r\nWhat’s more, even when victims’ were able to supposedly clean their environment by removing the malware and\r\nresetting passwords (but not the SAML private key), attackers could keep returning and accessing the victims’\r\nservices with their forged SAML tokens.\r\nThe knee-jerk reaction: build another wall around private Keys\r\nThe automatic reaction when something we own is stolen is to add more layers of defense. This was precisely how\r\nthe Cybersecurity and Infrastructure Security Agency (CISA) reacted when they advised victims’ to store their\r\nhttps://zengo.com/ungilded-secrets-a-new-paradigm-for-key-security/\r\nPage 2 of 5\n\nprivate keys in a Hardware Security Module (HSM).\r\n״Strongly consider deploying a FIPS validated Hardware Security Module (HSM) to store on-premises token\r\nsigning certificate private keys. An HSM, aggressively updated, makes it very difficult for actors who have\r\ncompromised the system to steal the private keys and use them outside of the network״\r\nBut inherent weaknesses exist within this HSM recommendation. For a start, hardware solutions are much more\r\ncomplicated and expensive to deploy compared to software solutions. This meant CISA could only “strongly\r\nrecommend” this action and not mandate it as they did in other situations.\r\nAdditionally, HSM solutions need to be “aggressively updated,” as HSM vulnerabilities can allow attackers to\r\ngain access to private keys and steal them as before.\r\nGiven these limitations and the attackers’ demonstrated capability to penetrate highly protected systems, adding\r\nadditional security layers within the infected environment will likely prove ineffective. More radical thinking is\r\nrequired to solve this problem.\r\nWhat if we didn’t need PRIVATE KEYS?\r\nSystem administrators don’t require the private key itself. They just need to get SAML tokens signed. Instead of\r\nprotecting private keys within an infected environment, what if keys are stored in another domain to which the\r\nvictims have no access?\r\nHaving an external service that signs tokens but keeps the private key out of reach of system admins and potential\r\nhackers can be a step forward. However, this solution is far from perfect. \r\nThe external signing service must be trusted to keep private keys safe from theft and ensure only valid requests\r\nfrom the customers’ are signed and not from attackers.\r\nThe good news is we can use Secure Multi-Party Computation (MPC) and specifically Threshold Signatures\r\n(TSS) to solve this issue. \r\nUsing these state of the art cryptographic constructions, we can “split the atom” and create a private key in a\r\ndistributed manner. Half the key is created in the customers’ organization environment, while the other half is\r\ncreated in the external service environment. \r\nBoth parties must engage in a protocol that signs the token without revealing their part of the key to other parties\r\nto sign. The signature itself is the same as if it had been created with a single private key and validated with a\r\npublic key. Therefore, there is no need to adjust existing solutions to support this architecture.\r\nWhen a private key is distributed with TSS, attackers must compromise these two independent environments. As a\r\nresult, the SAML private key is protected, even if the customer’s environment is compromised. \r\nAdditionally, a customer’s need to trust the external service is eliminated. Even if the service becomes entirely\r\ncompromised or turns rogue, it cannot forge tokens independently.\r\nhttps://zengo.com/ungilded-secrets-a-new-paradigm-for-key-security/\r\nPage 3 of 5\n\nThe solution consists of two mandatory parts, TSS cryptography and the security architecture of an\r\nexternal service. It is the combination of these two parts that makes this solution effective. \r\nUsing TSS on its own and distributing the secret within the customer’s environment without an external service is\r\ninsufficient. This is because when a customer’s environment is fully compromised, attackers can put their hands\r\non all the distributed parties and extract the private key. On the other hand, using an external service to store keys\r\nwithout TSS is vulnerable to external service attacks, as described above. \r\nIt’s important to note that these TSS and MPC algorithms are not just theoretical but actually very practical. In\r\nfact, we at Zengo have been successfully using them for the last two years in our cryptocurrency wallet to protect\r\nour customers’ private keys – by splitting them between our servers and customers’ devices. We’ve made our\r\nimplementation code publicly available for the benefit of the community.\r\nApplying TSS to SAML is even easier than for cryptocurrency, as availability is not a problem. In cryptocurrency,\r\nusers’ funds are bounded to a specific private key, and therefore losing even a single part of that distributed key\r\ncan lead to loss of funds. As a result, we needed to develop dedicated solutions to prevent this from happening.\r\nThis is not a problem for SAML. If a key, or some part of it, is lost, a new one can be issued, as unlike\r\ncryptocurrency, the specific private key has no special meaning. Additionally, older tokens do not become obsolete\r\nas they can still be verified with the older public key, even when the private key is no longer available.\r\nOf course, while TSS with external service for SAML signing is a significant step forward, it’s not a panacea.\r\nAttackers can still generate requests to sign tokens online from the customers’ environment to the external signing\r\nservice.\r\nHowever, this is restrictive and requires attackers to work against the system.\r\nAttackers cannot persistently return to the environment after they’ve been kicked out.\r\nOnline attacks leave traces in logs, making the attack much more visible. In fact, splitting the signing\r\nbetween two environments adds more security, as there can be an audit log for both environments.\r\nAttackers need to compromise both to tamper them.\r\nAttackers may still add an additional pair of a private and a public key as further SAML authenticators to the\r\nenvironment (a la Skeleton Key attack). But this attack must be carried out in an online manner that’s highly\r\nvisible.  \r\nParting thoughts\r\nBy abusing golden secrets, attackers were able to take full control over the networks of some of the world’s most\r\nprotected organizations. This clearly indicates our current defense methods are insufficient and that new thinking\r\nis required.\r\nIn this post, we presented a radical but practical solution that can significantly reduce the chances of an attack like\r\nSUNBURST happening again. \r\nhttps://zengo.com/ungilded-secrets-a-new-paradigm-for-key-security/\r\nPage 4 of 5\n\nInstead of trying to keep golden secrets safe by adding additional protective security layers, organizations should\r\nstrive not to keep them exclusively in the first place.\r\nSecurely distributing the responsibility for these secrets to external services using Threshold Signatures is simply\r\na no-brainer. But it’s just the tip of the iceberg when it comes to how modern cryptography can significantly\r\nupgrade the security of organizations worldwide.\r\nSource: https://zengo.com/ungilded-secrets-a-new-paradigm-for-key-security/\r\nhttps://zengo.com/ungilded-secrets-a-new-paradigm-for-key-security/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://zengo.com/ungilded-secrets-a-new-paradigm-for-key-security/"
	],
	"report_names": [
		"ungilded-secrets-a-new-paradigm-for-key-security"
	],
	"threat_actors": [],
	"ts_created_at": 1775434751,
	"ts_updated_at": 1775826696,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/80abf336354d66090bb49b7efb48238074aae979.pdf",
		"text": "https://archive.orkl.eu/80abf336354d66090bb49b7efb48238074aae979.txt",
		"img": "https://archive.orkl.eu/80abf336354d66090bb49b7efb48238074aae979.jpg"
	}
}