SEAL is not immune to security risks. There are a wide range of attacks against SEAL, including:

• Attacks against the signer
• Attacks against the content
• Attacks against identity resolution
• Attacks against validation

This document covers many of the common threats and countermeasures.

In general, SEAL does not attempt to make every component of the internet trustworthy. Instead, it identifies the trust assumptions required to interpret a signature and makes those assumptions explicit.

As detailed in the specifications, SEAL uses a multi-state logic flow. It is not limited to a boolean "it's valid or not"; a SEAL signature can be valid, invalid, unverifiable (cannot validate the signature), or unattributable (the cryptography is valid, but the attribution to the domain cannot be confirmed). Different attacks can attempt to change the resulting state.

SEAL does not have a centralized key management system.

• Anyone can generate a key pair.
• Anyone can specify the domain.
• Anyone can specify the user-id.

SEAL does not prevent a user from generating a key pair and claiming to sign on behalf of some other domain.

Mitigation: Although SEAL does not prevent misattribution in the file, without control of the corresponding domain's DNS, the attacker cannot cause a properly functioning validator to associate that key with the claimed identity. This prevents impersonation.

At best, the attacker's false signature will appear unverifiable or unattributable. However, the domain can also issue a general revocation, where any key not explicitly permitted is treated as revoked, making the impersonation invalid.

If the private key is compromised, then an attacker can legitimately sign media as the domain.

Mitigation: SEAL supports multiple revocation options, including global revocation and time-based.

As mentioned in the specifications, an attacker could backdate media to a period before the revocation. This exploit is not limited to SEAL; it impacts all PKI solutions. SEAL makes the additional recommendation of checking for other corroborating sightings of the media signed before the revocation date.

For local signing, the time is as trustworthy as the person who inserted it. A malicious user could backdate or postdate a signature.

Mitigation:

1. The timestamp is an assertion by the signer. SEAL does not inherently establish that the asserted time is correct; it only establishes who made the assertion.
2. For domains with multiple users, a user identifier at that domain may also be included. Any misleading timestamp may be attributed to a specific user.
3. A remote timestamp/signing service can provide a stronger time assertion because the requester does not control the timestamp generated by the service. This shifts the trust assumption from the content submitter to the remote signer.

A malicious signer can deliberately produce incorrect timestamps, or provide false signatures attributed to other users at the signing domain.

Mitigation: The signer does not make the time or user information true. Rather, it provides an independent attestation from a known attribution source.

To put it simple: Bad guys are not going to want to sign media with SEAL since the attribution will point directly back to the bad guy. In effect, this is security through accountability by using attribution as a deterrent. This approach is analogous to using motion-activated lights to secure a building. The lights don't physically stop the attacker; but the visibility discourages the attempt.

SEAL relies on DNS to distribute the public keys. DNS caching can cause validators to temporarily use an older public key after the domain owner has made changes or issued a revocation.

Mitigation:

The DNS TTL determines the maximum intended caching period (subject to resolver behavior) and is defined by the domain manager. SEAL validators MUST honor DNS TTLs and avoid treating cached DNS information as permanently authoritative.

Short-lived validation processes, such as SEAL-C, are not expected to run for more than a few minutes, manage no external cache files, and rely on the host operating system and upstream resolvers for longer caching. Short-lived processes do not need to closely track the TTL from each DNS lookup.

DNS is not a SEAL-specific trust mechanism. It is an existing distributed naming system that SEAL relies on for associating an identity with a public key. Consequently, attacks against DNS can affect SEAL validation in the same way that they affect other DNS-dependent security systems. The general DNS attacks includes:

• Modify the DNS response, such as forcing a valid result to appear invalid or unverifiable, or an invalid/revoked response to appear valid.
• Poison the DNS cache so subsequent requests receive the same modified response.

The security impact depends on the attacker's position in the DNS resolution path. An attacker capable of modifying the DNS response seen by a validator can potentially alter the validator's interpretation of a SEAL signature.

Mitigation:

DNS's distributed design effectively defeats most generic attacks. (This is not security by design, but rather security by infeasibility.)

• The attacker usually does not know who will be doing the validation, when the lookup will happen, or where the request will be coming from.
• The attacker typically does not know the internet route the query will take. If they cannot see the request, then they cannot intercept or replace it.
• When there is no ability to observe or interfere with the validator's DNS traffic, targeted DNS manipulation becomes a blind attack and is substantially more difficult to accomplish.
• There are different tiers of DNS relays, which impacts an attacker's ability to interfere with the DNS request:
  • The larger relays, including major public resolvers (e.g., Google and CloudFlare), Root, and top-level directory (TLD) operators are hardened against most attacks.
  • There are roughly 10 million open intermediary resolvers. Each relays for a small portion of the internet. It is impractical for an attacker to poison all of them, and virtually impossible to poison all of them at the same time. Just poisoning a few is unlikely to reach someone who is using SEAL at that moment to validate a specific file.
• DNS cache poisoning is difficult and caches expire/refresh within 24 hours. (Some services only cache for 1 hour, others use 10-24 hours. More than 24 hours is extremely uncommon, even if the DNS response specifies a longer TTL duration.) A malicious user cannot realistically maintain a long-running poisoning campaign without being noticed and having their attack blocked.
• An attacker could use BGP poisoning to hijack all traffic for a larger nameserver. However, these attacks are uncommon, (usually) noticed quickly, and are rapidly resolved. These are not long-duration attacks.

Due to DNS's caching nature, the impact from any caching attempt is typically resolved shortly (hours at most) after the attack stops.

There are solutions that could help secure DNS:

• DNSSEC: This extension to DNS cryptographically signs responses and prevents modifications to the DNS response without detection. However, DNSSEC is not a panacea:
  • On domain registrants, DNSSEC is typically disabled by default. Each domain registration must independently enable DNSSEC at each domain.
  • On user operating systems, DNSSEC is typically disabled by default. Enabling it requires OS-specific changes and may be too technical for typical users.
  • DNSSEC stops alterations, but does not prevent removal. Downgrade attacks are very feasible and can happen naturally. For example, some DNS relays remove unsupported DNS response results, and that can include the DNSSEC records.
• DoT and DoH: DNS over TLS (DoT) and DNS over HTTPS (DoH) are relatively new technologies and secure the last mile (first relay) connection. End-to-end DoT or DoH connectivity would secure the entire DNS lookup. However, these protocols have even lower adoption rates than DNSSEC and are much more difficult to enable and configure; common use is still years away.

Assuming the attacker can modify a SEAL DNS response, an attacker can:

• Remove the public key, causing media to appear unverifiable.
• Insert a revocation record, causing valid media to appear revoked.
• Remove a revocation record, causing revoked media to appear valid.
• If the attacker can send you media to evaluate, then they can provide a forged DNS response to make the media appear attributed to some other user (impersonation via false keys and DNS injection).

Mitigation:

SEAL strongly recommends enabling DNSSEC, but does not currently require it.

• Requiring DNSSEC would break compatibility with domains that do not have it enabled, or along network segments that do not support DNSSEC.
• SEAL validators SHOULD use DNSSEC, but MUST fall back to ordinary DNS and accept its weaker trust model. The validator SHOULD be informed whether the response came from DNSSEC or DNS.

Similarly, SEAL recommends enabling DoT or DoH when possible to protect the connection from the client to the first DNS resolver. However, due to DoT and DoH being transparent transport mechanisms, the validator may be unable to determine if either protocol was used.

Someday in the future, when DNSSEC, DoT, or DoH have better adoption rates, SEAL will change from recommending these solutions to requiring them.

As with other types of DNS attacks, when the attack stops, the impact automatically gets resolved. There is no permanent compromise or long-term damage to the SEAL validation process.