A multi-factor authentication system I am creating. Presented at Texas Linux Fest 2013.

1. libmufactlibmufact
A GPLv3 Multi-Factor Authentication System
Charles Southerland
Texas Linux Fest 2013

2. Outline
● Current Multi-Factor Options
● Design Considerations for libmufact
● How libmufact Works
● Q & A

3. Current Multi-Factor Options

4. Multi-Factor Authentication
● Authentication is commonly described as the
verification of one or more “factors”:
– Knowledge (“something you know”)
– Possession (“something you have”)
– Inherent Properties (“something you are”)
● Most computer authentication systems today rely
only on knowledge factors (specifically passwords).
● The use of multiple distinct factors can provide a
much greater assurance of authenticity.

5. The Need for Multi-Factor
● Major password leaks are now commonplace
– Sony
– Last.fm
– Match.com
● Most people reuse passwords between sites.
● Even if you never reuse passwords, an attacker
who has gleaned your password for a particular
site would be able to log in to that site whenever
they want without your knowledge.

6. Inherent Property Factors
● Biometrics (fingerprint, retina, etc. analyses) have
been a popular way of verifying something you are
(i.e. measuring specific properties inherent humans).
● Biometric verification devices have a horrible cost-to-
performance ratio over their entire price spectrum,
and are particularly bad about providing a false
sense of security.
● Verifying inherent properties of particular computers
has been an effective form of authentication at
times, but remains rare.

7. Possession Factors
● The vast majority of multi-factor authentication
systems add the verification of possession, as
these systems are generally much less
expensive and much more secure.
● Some systems claim to be based on
possession but use static data (thus providing
no freshness), and as a result are equivalent
to knowledge and not possession (e.g. credit
cards).

8. Connected Dedicated Devices
●
There have been many devices over the years which directly
communicate with a computer to verify possession (e.g. smart
cards, USB devices, etc.).
●
Most of these systems are very expensive and require custom
software and hardware.
●
Yubico has made some some devices lately that are much less
expensive and much more secure and convenient than most
others in this category, and so would probably be an excellent
choice.
●
Unfortunately, many end users find devices in this category
particularly burdensome, and so there is a lot of resistance to the
widespread adoption of any of these devices.

9. Disconnected Dedicated Devices
● RSA Security and Verisign have both produced
systems which use a dedicated device with a
displayed token that the user manually inputs to the
computer when authenticating.
● Since these tokens change with time, they maintain
freshness, thus minimizing the need for length.
● These systems are quite expensive, but have been
very popular among large organizations.

10. Disconnected Software Devices
● As smartphones have become more common-
place, many of the dedicated devices (e.g.
RSA Security's SecurID) now have equivalent
software versions which are less expensive
and seen as more convenient.
● Systems based on IETF RFCs 4226 and 6238
have recently risen in popularity (currently, the
most popular of these is Google
Authenticator).

11. Disconnected Device Issues
● As token-based possession factors ultimately rely on
symmetric cryptography, the security of the data
store for the symmetric keys is a single point of
failure.
● In March 2011, the RSA Security SecurID key
database was compromised despite it likely being
one of the most secured systems on earth.
● The small size of tokens are compensated by their
freshness, but they still limit key size.

12. Poorly Designed Systems
● Recently a number of poorly designed systems have
been touted as reasonable alternatives to serious
multi-factor authentication.
● Some sites have begun treating the selection of a
particular photo from a grid like a magical
authentication technique that isn't just another
knowledge factor like the password.
● Some sites have begun treating access to an email
inbox as a reasonable form of possession (e.g.
Facebook).

13. Design Goals of libmufact

14. Asymmetric Cryptography
● Asymmetric cryptography presents an
approach to possession verification that is
based on mathematics rather than
engineering, which I definitely liked.
● If asymmetric cryptography had been used
(including revocation certificates), the RSA
Security compromise could have been
resolved quickly and effectively without much
inconvenience to already reluctant users.

15. Internet-Connected Device
● Unfortunately, if asymmetric cryptography were used, the
tokens would be longer than a user could reasonably
enter, which requires the device to be connected in some
way.
● However, if we accept that the device mustmust be connected
in some way, we are free to take full advantage of such a
connection.
● Furthermore, it is not unreasonable to assume that a
smartphone would have access to the internet somewhere
where their computer has access to the internet.

16. Lock Up the Master Key
● When asymmetric cryptography is used in a one-to-many
fashion, the security of the one private key is a single
point of failure.
● However, if the one private key is used only to sign
temporary keys beforehand, there is no need to have this
master key present during active communication.
● The master public key could easily be distributed along
with the client, and the private key could be physically
separated from networked computers.

17. Simplified User Interface
● Since the device has a connection to the authenticating
site (albeit an indirect one), there is no need for the user
to enter additional information on the site.
● Unless additional information is also requested, the user
interface would be a simple approve/deny/ignore, not
dissimilar from an incoming call interface.
● With push notifications on mobile devices, the user would
be notified that there were authentication requests to be
responded to.

18. Client Key Reuse
● Given the asymmetric nature of the system, there
would be no need (outside privacy) to use separate
keys for separate sites.
● This could simplify the user interface further by only
requiring the user to unlock their private key once for
any number of sites making requests, which could all
be responded to simultaneously.
● This would be less inconvenient for those who wish
to supply their own key pairs.

19. Enhanced Privacy as an Option
● While these features simplify the user interface, an
individuals should be able to choose not to reuse keys,
receive push notifications, associate separate keys, etc.
in order to prevent the server from accumulating such
information.
● While some users may want their request history
purged, the user should not be given the false sense of
security that there is any way for them to know whether
or not the history was truly purged.

20. Additional Requested Data
● It could be possible to request additional
information from a user in some circumstances
in order to meet other goals.
● A user could sign information to be verified by
the site itself.
● If an expert user supplied the IP address of the
computer they were connecting from, then
three-factor authentication could be achieved,
and MitM attacks could be detected.

21. Does One Thing Right
● Mufact (which will be a complete multi-factor
authentication solution) will include libmufact as
one of its many pieces.
● While libmufact is not a complete authentication
system itself, it can be used to provide the core
functionality of one, thus leaving design decisions
like how to generate private keys, how to
communicate the binary blobs, how sites make
requests, etc. to the developer.

22. How libmufact Works

23. Outline of a libmufact Client
● Get the initial data from the server.
● Construct a conversation object from the data
and whichever operation you are most
interested in performing.
● Run a “reply loop”.
● Perform any remaining tasks based on the
conversation.
● Destroy the conversation object.

24. Transport Agnostic
● The developer is free to choose how the client
and server will communicate.
● In the case of the Mufact server I intend to
build, that will allow the developer of a client to
use the native HTTP client for their particular
platform.
● It could be possible to instead use HTTPS,
Apache Thrift, or even a home-grown protocol
on top of raw sockets or serial.

25. Conversation Constructors
●
get_lmf_conversation
– A normal conversation
●
update_key_lmf_conversation
– Start a conversation by informing the server about your updated key
● register_key_lmf_conversation
– Register with the server by providing your key and the registration
token
●
revoke_key_lmf_conversation
– Inform the server that your key is to no longer be trusted
●
… and a few more

26. Example
...
my_transport_data d = my_get( my_location );
lmf_conversation c = get_lmf_conversation(
d->data,
d->data_size,
master_public_key,
client_private_key,
client_key_id);
if (c == NULL) {
log(“OH NOES!!!”);
return FAILED;
}
...

27. Outline of a Reply Loop
1.Determine if there is an outbound message to send.
2.Perform the appropriate actions if the message indicates that a
revocation, update, or id assignment was received.
3.Run a “response loop” if the message is a response message.
4.Perform any other desired actions based on the message type.
5.If the message is now ready to send, prepare and send the
message, saving the reply into the conversation.

28. Notes on the Reply Loop
● A reply loop is used in order to avoid the risk of a client sending the
wrong information at the wrong time in an insecure manor.
● Many outbound messages reported in the reply loop will not be
sent; they are just present to relay information to the client.
● Some outbound messages that do not require action may still need
to be sent for security reasons, so it is important to check for and
send outbound messages that are ready to be sent regardless if
they were a type which a client would otherwise perform some
action based on receiving.

29. Requirements of a Reply Loop
● For security reasons, it is imperative that master key
revocation and update acknowledgement messages
be checked for (and if found, properly handled) at
every iteration.
● It is also necessary to check for key ID assignment
acknowledgement messages at every iteration or the
client will be unable to communicate with the server
next time.
● In order for a client to be useful, it should also check
for a response messages.

30. Example
...
lmf_outmsg o;
while((o = next_lmf_outmsg(c)) != NULL) {
if (is_lmf_msg_ack_revoke(o)) {
my_revoked_master_key_handler(c, o);
} else if (is_lmf_msg_ack_update(o)) {
my_updated_master_key_handler(c, o);
} else if (is_lmf_msg_ack_assign(o)) {
my_assign_key_id_handler(c, o);
} else if (is_lmf_msg_responses(o)) {
// << response loop goes here >>
} // other checks go here (maybe for logging?)
if (is_lmf_msg_ready(o)) {
char* msg_to_send = output_lmf_outmsg_b64(c, o);
data = my_transport_post(my_location, msg_to_send);
input_lmf_inmsg(c, d->data, d->size);
}
}
...

31. Outline of a Response Loop
1.Determine if there is an outbound response to send.
2.Display whatever information may be useful to
deciding how to respond to the request.
3.If the request should not be ignored, set whatever
information may be needed in the outbound response.
4.If the request should not be ignored, add the response
to the conversation's response queue.

32. Notes on the Response Loop
● The response loop is not based on the outbound
response type in the way that the reply loop is based on
the outbound message type because which response
type is sent could change based on what information is
provided to the outbound response.
● In addition to the possibility of ignoring requests, a
programmer can choose to control how many
responses are sent at once by choosing to stop
requesting the next outbound response.

33. Example
...
lmf_outresponse r;
while((r = next_lmf_response(c)) != NULL) {
my_user_response mur = my_show_request(r);
if (mur->ignore) {
ignore_lmf_response(c, r);
} else {
set_lmf_response_approval(r, mur->approved);
queue_lmf_response(c, r);
}
}
...

34. Outline of a libmufact Server
1.Send the pre-generated message made by the master key for
distribution.
2.Once a message has been received from a client and decrypted
by the temporary key, it needs to be combined with the client's
public key to construct a conversation object.
3.Something like the client's reply loop is then run, but with a
response issue loop replacing the response loop and the addition
of a “requests” outbound message that expects the server to add
requests to the queue if there are any.
4.Finally, the conversation object is destroyed.

35. Developing a libmufact Server
● A libmufact server will be a much trickier thing to build than a
libmufact client, as much more of the functionality is up to the
developer.
● In addition, a libmufact server will likely be the one responsible
for handling unusual circumstances (like an infinite response
loop or reporting odd response issues).
● Determining best practices for building a libmufact server will
likely be an ongoing process that will begin in earnest once
someone tries to make a server that behaves in a notably
different way from the main Mufact server.

36. Master Key Message Generation
● Update temporary key messages are
generated by the master key on a separate
machine well away from the internet.
● These messages (along with revocations or
updates) are given to the server to distribute
as the first message received by clients.

37. Example
$ lmf-sign-temporary-key
master-private-key.pem
temporary-public-key-06-01-2013.pem
$(date -d “June 1 2013” +%s)
> message-for-06-01-2013.txt
Setting effective start time to:
0x51A93980
Signing message...
Done!
$ cp message-for-06-01-2013.txt /mnt/thumb
$ cp temporary-private-key-06-01-2013.pem /mnt/thumb

38. Status of libmufact Today
● I'm getting close, but libmufact is not ready yet.
● Unfortunately, I'm the only one working on this project right
now.
● I've had a few distractions over the last 6 months:
– Job hunting
– Moved
– Helped my sister move
– Helped revive a cool local tech conference
– An unexpected death in the family
– Tornado

39. Questions?

40. If you are interested in using libmufact or Mufact,
please email me at:
charlie@stuphlabs.comcharlie@stuphlabs.com

41. Thank You!