Thursday, 25 October 2012

QR codes will make you thin!

The UK, like many 1st world countries is getting fat. In the near future all major supermarkets in the UK will adopt 'traffic-light-labeling' in the near future.



Indeed there is some evidence that consumers find traffic light labeling useful in determining their food choices. Unfortunately there's currently no good way of aggregating all of the food choices you make together to demonstrate what you're eating like on a daily or weekly basis. Can you have that cheeky pizza or tub of ice cream without going over your calorific recommendations? How many greens equal a red?




There's a whole bunch of calorie tracking applications out there but they can be fiddly and I find that of the one's I've tried generally I end up manually inputting information about what I'm eating, this is time consuming and a real pain in the ass. This is because these apps need to know what products you're eating. They maintain a database somewhere that looks up EAN codes and hopefully returns you some useful information. This is where many apps in the UK fall down with only limited coverage of our millions of food and drink options.






I think the standardization of a traffic light style system is useful but unless you're very strict when shopping, it's difficult to know what ratio of green, amber and red makes sense.

Instead I suggest that supermarkets work to make the nutritional information about a product available in-store in a computer-readable way. Two obvious ways to do this are NFC and QR codes. The smartphone is ubiquitous and if nutritional information were trivially accessible it would be trivial to write apps that can accurately track your purchases. Applications could easily be created that look at this data over time, or look at whole-family purchases to busy parents make more informed decisions and understand better what their consumption patterns are really like.


I mention NFC and QR codes above, these could deployed in two ways - on products or on the shelf, this is a very cheap option as supermarkets are constantly changing and updating their labeling anyway. On products would be more expensive but has the advantage that users could scan their items at home, as they're consumed as well as the time of purchase.


Another benefit of presenting this information in a tech readable way is that it's easy to add a bunch more information than just traffic lights. You can add information on how many vitamins are provided in this product and allergy information too.

Tills could read this information so even if you didn't walk around with a smartphone at all the till could print out the nutritional information about your weeks shop on your receipt, even pointing out things that are on offer which would supplement your diet, of course they could do this when they look up the EAN codes but this requires lots of work, chatting with a product database etc the nice thing about presenting the information locally i.e on the products is that the calculating of nutritional information and ratios becomes simple.

Imagine walking around a supermarket, you've told the application on your phone that you're doing a weeks worth of shopping. The application knows that you're trying to loose weight, that you need a certain amount of protein in your diet and that you're allergic to nuts. As you walk around the supermarket each item is scanned as you put it in your basket. You get a little beep to let you know that the fancy bread you just put in may contain nuts and you get a readout telling you if your diet this week is going to be higher in fat than you'd like or if you need to go grab some chicken because it's low in protein. A good application would probably store your previous purchases in a database so that that it can show you trends over time. If products did have a QR code printed next to the traffic light label then it would mean that once you've done your shopping and returned home you could track what you're eating, as you eat it. That would allow you to do some really interesting analysis of your eating habits.



There's lots of scope here for a supermarket to create an app that does all this and in turn offers targetted adds, perhaps specific discounts etc - there's a lot that can be done.

I like the idea of having the information in the QR code because it means I don't need internet access on my phone and makes the technological requirements for understanding the nutritional value of an item very low. Camera + QR reader = Done. When you make something like this Cloud based you have to be able to connect (WiFi or 3G) download (IP/TCP Stack) and interpret data from the supplier. However, something that used the QR code to grab a link to some Cloud based resource would perhaps be more valuable to a supplier. Who would be interested to know that their items were getting scanned 100k times but only being purchased 10% of the time? - they need to look at their nutritional info. I think this is exciting as it would allow users to start driving nutritional requirements back up to suppliers in a very real way, rather than focus groups and surveys.

For me, I'd like nutritional information on packaging exposed in a way that my phone can interpret, then I can spend weeks writing an app to help me with my dieting rather than going for a run!












Friday, 12 October 2012

Expired CRLs?

We put lots of trust in SSL and often it's miss-configured or the libraries we use don't check all that we'd expect.

Many python libraries fail open in the case of SSL errors and revocation lists aren't even installed in most Linux distributions by default and don't tell me this is because of OCSP, that's virtually never implemented outside of web browsers.

I started to question the diligence that was being performed by package maintainers who we trust with all our secrets - those who provide the installed CA Certificates that we can check the validity of certificates against.

I wrote a simple script that walks through a directory filled with certificates, parses them for CRL information, downloads it and looks to see if it's expired. The code is a little ropy but was written for a specific purpose.

I was surprised to find 6 different root CA's with expired CRLs. This means that if one of their subordinate issuing CA's has been compromised and revoked, I'd never know - in turn any of those CA's could continue to sign bad certificates that my system would honor (if it checked revocation in the first place).

This script could easily be modified to check websites certificates or similar but for now it serves my purpose.

Here's a link to the script:
https://github.com/hyakuhei/CRL-Scrape

and here's the output when run on a stock Ubuntu 11.10 machine:

ubuntu@server-1345473124-az-3-region-a-geo-1:~/CRL-Scrape$ python scrape.py /etc/ssl/certs/
signet_ca2_pem.pem has a CRL pca2.crl that expired on Jan 4 11:44:13 2008 GMT
b4f0b7e7.0 has a CRL LCRacraiz.crl that expired on Dec 19 18:08:57 2011 GMT
signet_ocspklasa2_pem.pem has a CRL klasa2.crl that expired on Jan 5 10:36:58 2007 GMT
3e223c08.0 has a CRL rootca.crl that expired on Jan 5 12:32:13 2008 GMT
signet_tsa1_pem.pem has a CRL klasa1.crl that expired on Aug 3 09:38:22 2006 GMT
signet_ocspklasa3_pem.pem has a CRL klasa3.crl that expired on Jul 1 10:56:24 2006 GMT

Perhaps we should look at weather signet should really be in this bundle of trusted Certificate Authorities?

Wednesday, 25 July 2012

Nessus OOM FFS

A year or two ago I setup a number of Nessus servers monitoring a few /16 network blocks.

Now I find that generating reports doesn't work, it seems to be getting out-of-memory errors while attempting to perform XSL translations on the reports.

A while back I wrote a script that aggregates reports together from various Nessus servers and creates a single report. This is useful because you can have some sections of your 'production' network scanned with one profile and others with a second profile - the script can put it all together as a single report for the 'Production' network - mail stakeholders with summary information etc.

So luckily I can get around the OOM errors by slicing up my networks into smaller chunks and scanning separately and gluing back together afterwards automagically!

I suspect others are in a far crappier situation. I can't share the script here but will help people out who are trying to do the same thing, lots of people appear to be struggling with this:

https://discussions.nessus.org/thread/2120;jsessionid=E9CDE4763C791FC9778A6AAE2283FBAC
https://bugs.nessus.org/message/16205;jsessionid=5A10E85F73FB36AAF8172B6558FD10E4?tstart=0
https://discussions.nessus.org/message/16662?tstart=0

Wouldn't it be nice if Tenable fix this before we all find better alternatives?


Monday, 23 July 2012

Encrypting files using SSH Keypairs and OpenSSL

There are a number of reasons why you don't want to do this, go and use GPG or something similar to perform your encryption. 


That said, if you're in a situation where you have a secret that needs securing before transmission to a specific party and the only credential for the recipient you have is their SSH Public Key then read on...


To start with you're going to need OpenSSL and SSH installed, we need SSH to convert the keys and we'll perform the actual encryption using OpenSSL.


Use SSH to convert the normal public key into something more usable by OpenSSL:

ssh-keygen -f id_rsa.pub -e -m pkcs8 > id_rsa.pub8

Use OpenSSL to encrypt 'secrets.txt' using the public key:
openssl rsautl -encrypt -inkey id_rsa.pub8 -pubin -in secrets.txt -out secrets.ssl

The recipient of the file can decrypt it using their corresponding private key:
openssl rsautl -decrypt -inkey id_rsa -in secrets.ssl -out secrets.txt

Voila! Simple public key encryption using SSH keys.

Be aware that we are doing direct RSA encryption here, which means you can only encrypt very small amounts of data. Anything bigger will typically use a symmetric algorithm like AES for encryption and use RSA to protect the AES key.