[TIPS] Variables can be nested!

[sebastian]

Found out this neat feature of iPXE:

set testvalue0 1234
set testvalue1 4567
set index 0
echo ${testvalue${index}}
>1234
set index 1
echo ${testvalue${index}}
>4567

This can be used to "create" simple encryption/authentication algoritms, even if those aren't "secure", you can for example prevent causual listening in a network. (just as a "obfuscation")

[mcb30]

(2014-03-20 11:20)sebastian Wrote:  This can be used to "create" simple encryption/authentication algoritms, even if those aren't "secure", you can for example prevent causual listening in a network. (just as a "obfuscation")

If you want security, you might be interested in iPXE's support for HTTPS and code signing: http://ipxe.org/crypto.

Michael

[sebastian]

I checked it out.
The only security I want, is the ability to protect a value against tampering across the network.

It would actually be enough with some like:

set encryption ${securedata}mysecretpassword
set finalresult ${encryption:md5hex}
chain h**p://192.168.1.2/boot.cgi?${securedata}-${finalresult}

verifying the value on server would be simple as:
$value = $ENV{'QUERY_STRING'};
($secure, $md5) = split("-", $value);
if ($md5 eq md5_hex($secure."mysecretpassword")) {
#Do something trusted with $secure
}
else
{
print "Content-Type: text/plain\n\nInvalid data";
}

but theres no way in iPXE currently to hash a value stored in a variable.


I looked at all these certificate stuff and found out that embedding both a client certificate (to prevent "unauthorized" clients from submitting data) and a server certificate, makes the binary too fat to be embedded in the mobo ROM.

Since the real clients and the server is fully trusted and know each other (its under the same roof), it would be sufficent with a simple shared-secret system.


The security case is this:
While the computers are booting, the computers are fully trusted. Both the server and the clients trust each other, so theres no need for PKI at all, a simple shared secret is enough.

When the computer has fully booted, its no longer trusted. The user on one of the trusted clients could for example Wireshark the traffic, and then use a own computer on the network to attempt to gain access to Resources that only trusted clients should have.

The user base of the computers are constantly changing, so theres almost never a user that have constant access to one single computer.

So the security I will do, will be based on a simple chaining, Rolling code system.
This will create a very hard obstacle for my user base to pass: To be able to pass this system, they will need to wireshark while the computer are booting for the first time for that day (eg when the boot file containing a seed secret, is transferred to the client computer). If they don't, they will never see the seed secret, and they will not be abe to produce codes that the server will accept.

[mcb30]

(2014-03-20 12:10)sebastian Wrote:  I looked at all these certificate stuff and found out that embedding both a client certificate (to prevent "unauthorized" clients from submitting data) and a server certificate, makes the binary too fat to be embedded in the mobo ROM.

Since the real clients and the server is fully trusted and know each other (its under the same roof), it would be sufficent with a simple shared-secret system.

In that case, you can just use HTTP Digest authentication, which is supported in the standard (non-HTTPS) build. On the server side, create a .htaccess file containing something like:

Code:

AuthUserFile /etc/htpasswd
AuthGroupFile /dev/null
AuthName "Restricted area"
AuthType Digest
require user myuser

and create the password file using

Code:

htpasswd -c /etc/htpasswd "Restricted area" myuser

and access the resource within iPXE using the syntax

Code:

http://myuser:mypassword@my.web.server/path/to/boot/file

HTTP Digest protects against replay attacks; if that's all you're concerned about then that would be sufficient.

Michael

[sebastian]

Great idea!
Which RFC are the digest auth that is implemented in iPXE based on?
RFC2069 or RFC2617?
(2617 is a later version of 2069)

[sebastian]

Actually, I found out a better way to do the server side authentication:

Use Apache Rewrite rules to set:
RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

Then I did do the actual verification in CGI, eg, I can do the verification in perl as:

if ($ENV{'HTTP_AUTHORIZATION'}) {
# Do md5 hashing and challenge verification.
}
else
{
# Create $servernonce
print "Status: 401 Unauthorized\n";
print "WWW-Authenticate: Digest realm=\"ipxe\", nonce=\"$servernonce\"\n";
print "Content-Type: text/plain\n\n401";
}

Since only one instance of each client can be booting at the same time, verification can easly be done by storing $servernonce, calculated in a certain way, in the server. Thus only one nonce is valid at a time, for a specific client with IP X.

This means I can add and remove users (based on their access card details) on the server dynamically without having to fumble with .htaccess.


I also combined this with my idea.
So the username and password used to authenticate, is calculated dynamically by using 2 10x10 tables, this takes 40 lines with "set" in the boot script to create 2 tables of 10x10 size.
each row contains a value 0-9 that maps to CARD ID DIGIT, and each column maps to PLACE IN ID (eg first digit has 0, second digit has 1 and so on), and the cell value is between 2 and 254, which is caculated by using "inc" command.

This makes it subsuquently much harder to use wireshark to listen in for the CARD IDs (125khz tags) of the users.

When the system is done, I will also compile in a secret client password inside the iPXE binary that is flashed into BIOS, to make it even harder to authenticate as a Another user without using the card reader.