Your SlideShare is downloading. ×
libmufact: A GPLv3 Multi-Factor Authentication System
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

libmufact: A GPLv3 Multi-Factor Authentication System

895
views

Published on

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

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

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
895
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. libmufactlibmufactA GPLv3 Multi-Factor Authentication SystemCharles SoutherlandTexas 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 theverification of one or more “factors”:– Knowledge (“something you know”)– Possession (“something you have”)– Inherent Properties (“something you are”)● Most computer authentication systems today relyonly on knowledge factors (specifically passwords).● The use of multiple distinct factors can provide amuch 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 attackerwho has gleaned your password for a particularsite would be able to log in to that site wheneverthey want without your knowledge.
  • 6. Inherent Property Factors● Biometrics (fingerprint, retina, etc. analyses) havebeen 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 falsesense of security.● Verifying inherent properties of particular computershas been an effective form of authentication attimes, but remains rare.
  • 7. Possession Factors● The vast majority of multi-factor authenticationsystems add the verification of possession, asthese systems are generally much lessexpensive and much more secure.● Some systems claim to be based onpossession but use static data (thus providingno freshness), and as a result are equivalentto knowledge and not possession (e.g. creditcards).
  • 8. Connected Dedicated Devices●There have been many devices over the years which directlycommunicate with a computer to verify possession (e.g. smartcards, USB devices, etc.).●Most of these systems are very expensive and require customsoftware and hardware.●Yubico has made some some devices lately that are much lessexpensive and much more secure and convenient than mostothers in this category, and so would probably be an excellentchoice.●Unfortunately, many end users find devices in this categoryparticularly burdensome, and so there is a lot of resistance to thewidespread adoption of any of these devices.
  • 9. Disconnected Dedicated Devices● RSA Security and Verisign have both producedsystems which use a dedicated device with adisplayed token that the user manually inputs to thecomputer when authenticating.● Since these tokens change with time, they maintainfreshness, thus minimizing the need for length.● These systems are quite expensive, but have beenvery popular among large organizations.
  • 10. Disconnected Software Devices● As smartphones have become more common-place, many of the dedicated devices (e.g.RSA Securitys SecurID) now have equivalentsoftware versions which are less expensiveand seen as more convenient.● Systems based on IETF RFCs 4226 and 6238have recently risen in popularity (currently, themost popular of these is GoogleAuthenticator).
  • 11. Disconnected Device Issues● As token-based possession factors ultimately rely onsymmetric cryptography, the security of the datastore for the symmetric keys is a single point offailure.● In March 2011, the RSA Security SecurID keydatabase was compromised despite it likely beingone of the most secured systems on earth.● The small size of tokens are compensated by theirfreshness, but they still limit key size.
  • 12. Poorly Designed Systems● Recently a number of poorly designed systems havebeen touted as reasonable alternatives to seriousmulti-factor authentication.● Some sites have begun treating the selection of aparticular photo from a grid like a magicalauthentication technique that isnt just anotherknowledge factor like the password.● Some sites have begun treating access to an emailinbox as a reasonable form of possession (e.g.Facebook).
  • 13. Design Goals of libmufact
  • 14. Asymmetric Cryptography● Asymmetric cryptography presents anapproach to possession verification that isbased on mathematics rather thanengineering, which I definitely liked.● If asymmetric cryptography had been used(including revocation certificates), the RSASecurity compromise could have beenresolved quickly and effectively without muchinconvenience to already reluctant users.
  • 15. Internet-Connected Device● Unfortunately, if asymmetric cryptography were used, thetokens would be longer than a user could reasonablyenter, which requires the device to be connected in someway.● However, if we accept that the device mustmust be connectedin some way, we are free to take full advantage of such aconnection.● Furthermore, it is not unreasonable to assume that asmartphone would have access to the internet somewherewhere their computer has access to the internet.
  • 16. Lock Up the Master Key● When asymmetric cryptography is used in a one-to-manyfashion, the security of the one private key is a singlepoint of failure.● However, if the one private key is used only to signtemporary keys beforehand, there is no need to have thismaster key present during active communication.● The master public key could easily be distributed alongwith the client, and the private key could be physicallyseparated from networked computers.
  • 17. Simplified User Interface● Since the device has a connection to the authenticatingsite (albeit an indirect one), there is no need for the userto enter additional information on the site.● Unless additional information is also requested, the userinterface would be a simple approve/deny/ignore, notdissimilar from an incoming call interface.● With push notifications on mobile devices, the user wouldbe notified that there were authentication requests to beresponded to.
  • 18. Client Key Reuse● Given the asymmetric nature of the system, therewould be no need (outside privacy) to use separatekeys for separate sites.● This could simplify the user interface further by onlyrequiring the user to unlock their private key once forany number of sites making requests, which could allbe responded to simultaneously.● This would be less inconvenient for those who wishto supply their own key pairs.
  • 19. Enhanced Privacy as an Option● While these features simplify the user interface, anindividuals should be able to choose not to reuse keys,receive push notifications, associate separate keys, etc.in order to prevent the server from accumulating suchinformation.● While some users may want their request historypurged, the user should not be given the false sense ofsecurity that there is any way for them to know whetheror not the history was truly purged.
  • 20. Additional Requested Data● It could be possible to request additionalinformation from a user in some circumstancesin order to meet other goals.● A user could sign information to be verified bythe site itself.● If an expert user supplied the IP address of thecomputer they were connecting from, thenthree-factor authentication could be achieved,and MitM attacks could be detected.
  • 21. Does One Thing Right● Mufact (which will be a complete multi-factorauthentication solution) will include libmufact asone of its many pieces.● While libmufact is not a complete authenticationsystem itself, it can be used to provide the corefunctionality of one, thus leaving design decisionslike how to generate private keys, how tocommunicate the binary blobs, how sites makerequests, 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 dataand whichever operation you are mostinterested in performing.● Run a “reply loop”.● Perform any remaining tasks based on theconversation.● Destroy the conversation object.
  • 24. Transport Agnostic● The developer is free to choose how the clientand server will communicate.● In the case of the Mufact server I intend tobuild, that will allow the developer of a client touse the native HTTP client for their particularplatform.● It could be possible to instead use HTTPS,Apache Thrift, or even a home-grown protocolon 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 registrationtoken●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 Loop1.Determine if there is an outbound message to send.2.Perform the appropriate actions if the message indicates that arevocation, 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 themessage, 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 thewrong information at the wrong time in an insecure manor.● Many outbound messages reported in the reply loop will not besent; they are just present to relay information to the client.● Some outbound messages that do not require action may still needto be sent for security reasons, so it is important to check for andsend outbound messages that are ready to be sent regardless ifthey were a type which a client would otherwise perform someaction based on receiving.
  • 29. Requirements of a Reply Loop● For security reasons, it is imperative that master keyrevocation and update acknowledgement messagesbe checked for (and if found, properly handled) atevery iteration.● It is also necessary to check for key ID assignmentacknowledgement messages at every iteration or theclient will be unable to communicate with the servernext time.● In order for a client to be useful, it should also checkfor 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 Loop1.Determine if there is an outbound response to send.2.Display whatever information may be useful todeciding how to respond to the request.3.If the request should not be ignored, set whateverinformation may be needed in the outbound response.4.If the request should not be ignored, add the responseto the conversations response queue.
  • 32. Notes on the Response Loop● The response loop is not based on the outboundresponse type in the way that the reply loop is based onthe outbound message type because which responsetype is sent could change based on what information isprovided to the outbound response.● In addition to the possibility of ignoring requests, aprogrammer can choose to control how manyresponses are sent at once by choosing to stoprequesting 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 Server1.Send the pre-generated message made by the master key fordistribution.2.Once a message has been received from a client and decryptedby the temporary key, it needs to be combined with the clientspublic key to construct a conversation object.3.Something like the clients reply loop is then run, but with aresponse issue loop replacing the response loop and the additionof a “requests” outbound message that expects the server to addrequests 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 alibmufact client, as much more of the functionality is up to thedeveloper.● In addition, a libmufact server will likely be the one responsiblefor handling unusual circumstances (like an infinite responseloop or reporting odd response issues).● Determining best practices for building a libmufact server willlikely be an ongoing process that will begin in earnest oncesomeone tries to make a server that behaves in a notablydifferent way from the main Mufact server.
  • 36. Master Key Message Generation● Update temporary key messages aregenerated by the master key on a separatemachine well away from the internet.● These messages (along with revocations orupdates) are given to the server to distributeas 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.txtSetting effective start time to:0x51A93980Signing 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● Im getting close, but libmufact is not ready yet.● Unfortunately, Im the only one working on this project rightnow.● Ive 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!