Re: [OATH-Toolkit-help] PSKC file locking

[David Woodhouse]

On Thu, 2014-08-14 at 16:54 +0200, Simon Josefsson wrote:
> Ok now the use-case is clearer to me.
> 
> Would it make sense to import the PSKC data into another file instead,
> before you can use it?

The issue is that the token is *shared*, so importing it into
per-application storage and making it "the application's problem" isn't
a viable approach.

I might use it from the VPN client and bump the counter once, and then I
might need to generate the next tokencode manually to enter into a web
page. It *can't* be a solution which is private to the individual
application.

So copying the data into "another file" just shifts the issue, which is
that to coherently support HOTP on the client side we need *some*
consistent way for applications to be able to access a token and
atomically update it as they use tokencodes.

> PSKC was intended for transportation, so it isn't ideal for this kind
> of read-write-cycles. 

PSKC is no worse than any other format really. We'll always have to have
locking to protect against concurrent access and two applications using
the same tokencode, so a format which lets us just rewrite the counter
value in-place instead of rewriting the whole file doesn't really give
us much of an advantage.

If we need a shared format for applications to use on the client side
where it's just a single key, I'm not sure why we *wouldn't* use PSKC.

>  But since this is outside of oath-toolkit, it is fine to do this if 
> you want to…

But I don't *want* it to be outside of oath-toolkit :)

I actively Do Not Want to implement this in my own client — and more to
the point I don't want to trust that other applications will implement
it correctly too, and refrain from screwing me over.

There has to be a common, system-wide agreement on how this is handled,
and for me that's a really strong hint that it lives in a common library
— and surely oath-toolkit is the right place for it?

I'm happy to implement it; I'm not just being lazy. I just don't want to
*keep* it. :)

And while we're at it, we could also implement a tool which fixes all
the horrid issues in the script I'm currently using for manually
generating tokencodes:

#!/bin/sh
FILE="$1"

if [ ! -r "$FILE" ]; then
    echo Cannot read Key file "$FILE"
    exit 1
fi

# We actually have to parse the output; the return code doesn't help :(
FILEOK=$(pskctool -e "$FILE")
if [ "$FILEOK" != "OK" ]; then
    echo Failed to validate key file "$FILE"
    exit 1
fi


if pskctool -i "$FILE" | grep -q "KeyPackage 1:"; then
    echo There can only be one key in the file
    exit 1
fi

# Ah, screw it. Parsing the output of 'pskctool -i' is harder than parsing
# the XML in the first place.
KEY=$(xmlstarlet sel -t -v 
/_:KeyContainer/_:KeyPackage/_:Key/_:Data/_:Secret/_:PlainValue $FILE | base64 
-di | od -A none -t x1 -w40 | sed s/\ //g)
COUNTER=$(xmlstarlet sel -t -v 
/_:KeyContainer/_:KeyPackage/_:Key/_:Data/_:Counter/_:PlainValue $FILE)

# XXX Check for TOTP/HOTP mode, output format, etc.
oathtool -c $COUNTER $KEY

COUNTER=$(($COUNTER + 1))
xmlstarlet ed -L -u  
/_:KeyContainer/_:KeyPackage/_:Key/_:Data/_:Counter/_:PlainValue -v $COUNTER 
$FILE

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature