Network Working Group Michal Novotny Internet-Draft July 12, 2011 Intended status: Standards Track Expires: January 12th, 2012 Using MinCrypt data encryption system as a website security layer draft-novotny-mincrypt-00.txt Abstract This document describes using the mincrypt data encryption for the website encryption that could be used as an additional security layer to establish/increase the website security. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12th, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Novotny Expires January 12, 2012 [Page 1] Internet-Draft MinCrypt website security layer July 2011 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Algorithm description . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. Deployment design . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Deployment options . . . . . . . . . . . . . . . . . . . . . 4 3. DNS record specifications . . . . . . . . . . . . . . . . . . . 5 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Novotny Expires January 12, 2012 [Page 2] Internet-Draft MinCrypt website security layer July 2011 1. Introduction As already known the websites uses the SSL as the secure socket layer interface however having some better encryption would be a great thing. Some time ago I've been trying to implement several encryption algorithm to fulfill needs of the minimalistic application requiring the data encryption with providing a new algorithm. Recently I've developed the MinCrypt algorithm (the algorithm is open-source with the source codes available on http://www.migsoft.net/projects/minCrypt) that has been tested for several scenarios and the generation of initial vectors is being used based on the salt, password and optionally a vector multiplier values passed to the algorithm's core functions. Both salt and password are secret parts of the puzzle however if any of those parts is invalid the fictional encryption curse is shaped in the different angle because the vectors are being generated using the invalid input data. Optional vector multiplier value is just an add-on value for to extend the initialization vector size using additional mathematical operations which is useful for larger data blocks. The algorithm is open-source and already has both Linux and Windows libraries and binaries written and the PHP extension for Linux systems exist as well (most of the servers nowadays are both Linux-based and PHP is very wide-spread website development platform so this makes it easy to implement since the extension is already done by Michal Novotny, the mincrypt and this document's author). 1.1. Algorithm description The minCrypt algorithm itself is the simple symmetric encryption algorithm designed to be minimalistic to be used in routers, switches and various low cost devices with the option to be implemented in directly into hardware using the VHDL or FPGA technologies for programming chips since the algorithm itself is open-source under the LGPLv2+ licence. 1.2. Terminology The minCrypt algorithm is based on the design document written by it's author, Michal Novotny in turn of years 2010 and 2011. The initial version of the document is available on project's website however minCrypt project itself has been already upgraded in comparison to the draft design document there. Novotny Expires January 12, 2012 [Page 3] Internet-Draft MinCrypt website security layer July 2011 Although the document is out-of-date the terminology stands. The main terms for the systems are as follows: SALT - This is the salt value which should be kept secret as well as the password value. This is one of the key components required to run generate the initialization vectors. PASSWORD - Password value is the secret value that should be remembered by system user. This should be the variable value and it's one of the key components for the initialization vectors generation. VECTOR MULTIPLIER - Add-on component to generate the vectors. The default value should may differ in subsequent versions of the encryption system. The value is used to extend the initialization vectors array using mathematical calculations applied to the already generated vector components. This increases the security and alters the fictional encryption curve angle. 2. Deployment design To deploy the encryption layer using minCrypt on the server side you'll need to add SRV records and other servers and/or services to your network. Since the minCrypt encryption system design is counting with 2 or 3 values to be set in the we have basically 3 deployment options sharing the same logic pattern. Those options will be described in section 2.1 (Deployment options). The common diagram should be as follows: (6) +------------------------------------------------------+ | (3) | | +--------------------------------------------------+----------------+ | | | | (5)| | v v +--+---+---+ +----------+ +----------+ | Client | (1) | Server | (7) | Password | | | -------------------------------------> | (web) + <-->+ server | +----------+ +-----+----+ +-----+----+ ^ ^ | | | | (2) | | | +--------------------------------------------------+ | | (4) | +-----------------------------------------------------------------------+ Novotny Expires January 12, 2012 [Page 4] Internet-Draft MinCrypt website security layer July 2011 where: 1) Client asks password server for the client's public IP address and also the password server location 2) Server acknowledges the request and sends client's public IP address and the password server location back to the client 3) Ask password server for the password generated for the client 4) Password server sends the password based on client's public IP address back to the client 5) Client encrypts the data using the salt, password and vector multiplier values it's having available either statically from the DNS SRV record, dynamically generated from the password server or set in the web-server configuration (which could be planned for the future). 6) The encrypted data are being sent to the server where the decryption and request serving is done. Both parties are having both encryption and decryption parts therefore. 7) The communication is being also established between web-server and password server to transfer the password data to the web-server for both client and password to allow both know the encryption/decryption keys. 2.1 Deployment options Since the encryption system itself is using 3 various values where two values are meant to be hexadecimal strings (password and salt) and one value is the integer value that should be in the range from 32 (2^5) to 65535 (2^16) which means 3 values in total the password server (or better say "secret"-server) for each value could be used. There are other options to be used if we don't want to use password server for each of those values and only using it e.g. for password value will meet our goals. There are several 3 options of deployment therefore: A) Use variable password with fixed salt and vector multiplier value B) Use both variable password and variable salt with fixed vector multiplier value C) Use variable password, variable salt and also variable vector multiplier value Of course there are other options like using variable salt value with fixed password or using fixed password and fixed salt values with variable vector multiplier value however those options seems to be useless and therefore I'm not considering them at all since the password should be the key component to be used all the time with possible add-ons of variable salt and vector multiplier components. For the fixed string components (salt) the client's MAC address could be used if we modify the web-browser to support sending such an identification in the headers (which should be no problem for Mozilla Firefox, Google Chrome and open-source web-browsers) or we can define the fixed value in the DNS SRV record directly. Novotny Expires January 12, 2012 [Page 5] Internet-Draft MinCrypt website security layer July 2011 3. DNS record specifications The SRV record in the DNS (or maybe a new kind of records) should be used for the password server specification. The DNS SRV records (or a new kind of them) could be optionally used for all of the values supported according to the requested deployment option, i.e. for option C of the deployment options the password-server, salt-server and also the vector-multiplier server could all be used and identified by the DNS server records. The port should be specified in the record to tell client where to connect to using the UDP connection. The SRV record for domain.tld (example domain name) will be present on the _passwordserver._udp.domain.tld. The UDP protocol will be used to get the IP address of the client and generate the new password based on the client's IP address. Not-connected protocol is better since if somebody would like to spoof the IP address and ask password server for the password for the desired IP address the server will discard all such request leaving client think that there's no password server present on such a port. Also, the urandom value could be used to generate the password since the encryption may be different per each request. The decryption should follow the pattern above except the password will be stored in the user's browser and regenerated any following request. Using this algorithm should be done only in the case of the password server present record (_passwordserver._udp.domain.tld) is present on the target domain you are trying to access with not using any of those otherwise. When found that the password server is present than client should check for the salt-server and also vector-multiplier server to determine what servers to use and what of the deployment options is being used. 4. References [mincrypt] http://www.migsoft.net/projects/minCrypt Author's Address Michal Novotny [ @ Red Hat but submitted as individual ] U Stadionu 34 568 02 Svitavy Czech Republic Email: mignov@gmail.com URI: http://www.migsoft.net[/projects/minCrypt] Novotny Expires January 12, 2012 [Page 6] Internet-Draft MinCrypt website security layer July 2011