![](bg2.png)
of a sender and the spammers can also adopt it to sign
their own messages. However, (Taylor, 2006) shows
that only 2% of spam received are authenticated by
DKIM, which is significantly less than the spam au-
thenticated by SPF.
In iSATS, we introduce a new email sender authen-
tication system that is based on identity based public
key cryptography (IBC) (Shamir, 1985). With IBC
a private key generator (PKG) or a trusted authority
(TA) is responsible for generating a secret key (SK)
against the identity of the domain used as public key
i.e. the TA is also responsible to thoroughly verify the
identity of a domain before issuing SK. This verifica-
tion strongly binds the identity of the domain owner
to its domain and makes it hard for the spammer to
adopt iSATS, unless they are willing to give away their
identity.
iSATS requires the sender’s Mail Transfer Agent
(MTA) to generate a signature using SK of the do-
main and append it along with SMTP envelop (MAIL
FROM). This enables the recipient’s MTA to quickly
authenticate the sender by verifying the appended sig-
nature. Any invalid connection is terminated right
away, saving valuable resources both at the MTA and
in the network. Finally, email forwarding and mung-
ing of message along the transit is not a problem in
iSATS.
2 iSATS DESIGN
iSATS is a crypto-based email sender authentication
system that operates on the SMTP envelop, in par-
ticular on MAIL FROM command, to perform do-
main level authentication during the SMTP time.
iSATS leverages identity based signature (IBS) using
identity-based public key cryptography (IBC) (Cocks,
2001; Boneh and Franklin, 2001) to authenticate the
identity of an email sender. Compared to tradi-
tional public key cryptography, IBC saves the burden
of managing and distributing the public keys, since
publicly available unique identities are used as pub-
lic keys. iSATS requires establishment of a trusted
authority (TA) also known as private key generator
(PKG), responsible for issuing secret key (SK) and
system parameters. The TA is also responsible to ver-
ify the identity of a domain before issuing the SK.
2.1 Basic Requirement
At the outset, we seek a solution that works well with
the current, entrenched system. This means that the
system should:
• Work as an optional addition to standard
mail clients or servers, and continue to sup-
port popular means of accessing mail (e.g.
IMAP/POP/Webmail).
• Be incrementally deployable.
• Remains transparent to end users.
The functionality of iSATS can be divided into four
steps: 1) setup, 2) identity verification and secret key
extraction, 3) signature generation and 4) signature
verification, discussed in the upcoming sections.
2.2 Setup
This step is executed once in the beginning and marks
the creation of a whole IBC environment by a TA. The
setup results in generation of Master Key and System
Parameters. Master key is kept secret by the TA and it
is used to generate SK for the domain based on their
identity. System parameters are publicly available.
2.3 Identity Verification and Secret Key
Extraction
This step is initiated when any domain wants to be-
come part of iSATS and requests a SK (see Figure 1).
iSATS represents a closed system, in a sense that do-
mains are not automatically added to the system but
the TA verifies their identity first. iSATS is envi-
sioned to provide extended validation of the domain’s
identity. Identity verification with Extended Valida-
tion (EVC, 2009) provides high-security information
to clearly identify a domain’s organizational identity.
This will help bind the owner’s identity to the iden-
tity of the domain and will make misbehaving do-
mains visible. Most well-known webmail providers
and websites tend to have SSL certificates with ex-
tended verification, so this requirement is not exces-
sive.
After identity verification, the TA will issue sys-
tem parameters and a SK corresponding to the do-
main name which is also its identity. This meets the
requirements of the system, as the domain name is a
unique identity for the domain and is publicly avail-
able to all parties.
2.4 Signature Generation
This step is executed when a user wishes to send
an email. The MTA will generate a signature
on the sending user’s email address (e.g. al-
ice@example.com) using the SK and system param-
eters of the domain. After doing this, the signature is
appended to MAIL FROM command as an additional
iSATS:LeveragingIdentitybasedSenderAuthenticationforSpamMitigation
409