[9fans] cryptographic signatures & factotum

[9fans] cryptographic signatures & factotum

[steve-simon]

Hi,

I want to reinvent a wheel.

I want to be able to send an email from home to work
which will cause my work machine to cpu(1) back to me.

To prevent mistakes and nasty people this should be
cryptographicially signed, PGP already does this, but
I don't fancy implementing or porting PGP.

I was thinking of just an email with 2 attachements
one being the command to execute, the other being an
SHA1 hash of this command followed by a shared secret.

The neatest way to check the has would be to pass the hash
of the command to factotum and let it hash the secret and
reply yea or nay.

I could write a seperate program and use proto=pass
to query factotum but why make it release secrets it needn't?

Anyone see any flaws?
Anyone know of facilities in factotum that do this already?
Other (relevant :-) thoughts?

-Steve

Re: [9fans] cryptographic signatures & factotum

[andrey mirtchovski]

you've looked at pipeto, right? you can easily embed relevant auth info in
the header or subject line and catch it in pipeto. people have done it lots
with procmail.

what really worries me is that htmlfmt is executed for each HTML email
that is viewed in plan9 suppose there was a bug in htmlfmt or any other
app plan9 plumbs to by default as soon as i can exploit htmlfmt i could
write a self-propagating virus for plan9.  as matt says, nedmail does
the same for images...

andrey

Re: [9fans] cryptographic signatures & factotum

[9nut]

> I want to be able to send an email from home to work
> which will cause my work machine to cpu(1) back to me.

I've not tried this, but I think it should work.

Why not run a cron job on the cpu at work (on your behalf and your
factotum), that dials home, and once it authenticated itself, runs
exportfs.  On the home system you'd run a service that authenticates
the incoming call and then posts the fd on /srv later you mount
/srv/incoming to /n/someplace.

The part i'm not sure of is the cron/factotum interaction.

Re: [9fans] cryptographic signatures & factotum

[George Michaelson]

one time pad? 

easier to port/code than GPG, reasonably secure, easy to deploy.

(in the class of hacks to tell the remote to call you back by some trigger event)

you could implement a MD5 challenge/response daemon which didn't reveal your
token over the wire pretty simply.

I've seen mention of some very simple schemes based on sequenced event delivery
eg send mail *and* some other event *and* some subsequent event, any one of
which is less secure than the combination of all three from the same endpoint.

-George

Re: [9fans] cryptographic signatures & factotum

[boyd, rounin]

> one time pad? 

key exchange & key security?

Re: [9fans] cryptographic signatures & factotum

[George Michaelson]

On Fri, 12 Mar 2004 01:09:29 +0100 "boyd, rounin" <boyd@insultant.net> wrote:

>> one time pad? 
>
>key exchange & key security?

yes. always an issue with otp. cost:benefit usually means making that kind of
judgement call. 

-George

Re: [9fans] cryptographic signatures & factotum

[Bruce Ellis]

an international phone call is often needed, talking in
silly speak of course, hey boyd?

brucee
----- Original Message ----- 
From: "George Michaelson" <ggm@apnic.net>
To: <9fans@cse.psu.edu>
Sent: Friday, March 12, 2004 11:30 AM
Subject: Re: [9fans] cryptographic signatures & factotum


> On Fri, 12 Mar 2004 01:09:29 +0100 "boyd, rounin" <boyd@insultant.net> wrote:
> 
> >> one time pad? 
> >
> >key exchange & key security?
> 
> yes. always an issue with otp. cost:benefit usually means making that kind of
> judgement call. 
> 
> -George
> 
> 

Re: [9fans] cryptographic signatures & factotum

[boyd, rounin]

> an international phone call is often needed, talking in
> silly speak of course, hey boyd?

yeah, idiolects and shared 'secret' data.

Re: [9fans] cryptographic signatures & factotum

[boyd, rounin]

although, i think i have figured out a 'near' OTP [short messages, frequent
key changes].

Re: [9fans] cryptographic signatures & factotum

[bs]

George Michaelson wrote:
> one time pad? 
> 
> easier to port/code than GPG, reasonably secure, easy to deploy.
> 
> (in the class of hacks to tell the remote to call you back by some trigger event)
> 
> you could implement a MD5 challenge/response daemon which didn't reveal your
> token over the wire pretty simply.
> 
> I've seen mention of some very simple schemes based on sequenced event delivery
> eg send mail *and* some other event *and* some subsequent event, any one of
> which is less secure than the combination of all three from the same endpoint.
> 
> -George
SASL & OTP (one time password)?

Re: [9fans] cryptographic signatures & factotum

[matt]

as well as the other good suggestions there's also port knocking

http://www.portknocking.org

which you can use like a combination lock 

m

Re: [9fans] cryptographic signatures & factotum

[a]

// ...I don't fancy implementing or porting PGP.

FWIW, note taht PGP "just worked" at some point. the
version numbers are foggy in my head just now, but i
think it was the 2.x tree. geoff did the port first,
but i recall doing it myself and it being pretty
straight-forward. i've not been using it for a few
years now, and have lost my work, but it might be
worth looking at again.

as i recall, newer versions didn't work without
more effort than i was willing to put in.


oh, and as an aside, on the naming thing: on lists
like this, i tend to refer to people either by
handle (user part of ema) or however they sign
their name, if handle's too difficult for me to
remember (or too long to type). just a note.
ア

Re: [9fans] cryptographic signatures & factotum

[rog]

> oh, and as an aside, on the naming thing: on lists
> like this, i tend to refer to people either by
> handle (user part of ema) or however they sign
> their name, if handle's too difficult for me to
> remember (or too long to type). just a note.

i do the same, which is why i found the okamoto affair a bit
difficult...  i'd refer to Kenji Okamoto as "okamoto" in the same way
i might refer to Jim McKie as "jmk", just 'cos that's his username.

i'm glad it wasn't me that blundered.

Re: [9fans] cryptographic signatures & factotum

[Geoff Collyer]

pgp has already been trivially modified and compiled on plan 9, for
what it's worth.  (Calling it a port is a stretch.) I use it a little
bit.

I wouldn't want to send the mail in the clear, so I'd send it over TLS
at minimum.

Does it need to be mail that triggers the cpu command?  Couldn't cpu
trigger it just as well?  That way you can use an encrypted cpu
session and just run some command, either one that schedules the
outbound cpu call or just makes the call:

	cpu -h work -c callhome

Re: [9fans] cryptographic signatures & factotum

[Steve Simon]

Hi,

Thanks to all who replied.
I realised I didn't say why I want to do this.

At work my plan9 system is very carefully screened behind a
firewall. The only way I can make somthing happen on it is
either cron or emai (via pipeto).

My idea was to send just a plaintext email that contains two attachements.
One being an rc script and the other an authenticating
signature for that command. I think this is secure enough as the
signature (hash) would need a shared secret to be validated.

The idea of hashing a sequence count is interesting but in the context
of email as a transport (and our unreliable pop3 server) I am wary of
going down this route.

The real questions are:
Should I attempt to add a non-standard (not PGP) signature verification
algorithm to factotum? Or, should I just do a quick bodge and not
worry, because no-one else would ever want such a thing?

Another question:

At home my plan9 system is straight onto broadband but I believe it's
secure - it only listens on the cpu and exportfs, am I being naieve (again
:-), tell me I don't need to buy a firewall...

-Steve

Re: [9fans] cryptographic signatures & factotum

[David Presotto]

On Fri Mar 12 04:25:49 EST 2004, plan9fans@ntlworld.nospam.com wrote:
> The real questions are:
> Should I attempt to add a non-standard (not PGP) signature verification
> algorithm to factotum? Or, should I just do a quick bodge and not
> worry, because no-one else would ever want such a thing?

I'ld rather you just finish the pgp implementation that I started and
rsc has gotten to (more or less?) work.  Perhaps he'll give you the code.

> 
> Another question:
> 
> At home my plan9 system is straight onto broadband but I believe it's
> secure - it only listens on the cpu and exportfs, am I being naieve (again
> :-), tell me I don't need to buy a firewall...

Yes, modulo my bugs in the security stuff.  Our password algorithm is
only DES.  Brute force would eventually work.  We should be moving to
a new alg.

Re: [9fans] cryptographic signatures & factotum

[boyd, rounin]

> Yes, modulo my bugs in the security stuff.  Our password algorithm is
> only DES.  Brute force would eventually work.  We should be moving to
> a new alg.

http://plan9.bell-labs.com/magic/man2html/4/factotum

By default when factotum starts it looks for a secstore(1) account on $auth
for the user and, if one exists, prompts for a secstore password in order to
fetch the file factotum, which should contain control file commands. An
example would be

      key dom=x.com proto=p9sk1 user=boyd !hex=26E522ADE2BBB2A229
      key proto=rsa service=ssh size=1024 ek=3B !dk=...

  where the first line sets a password for challenge/response
authentication, strong against dictionary attack by being a long random
string, and the second line sets a public/private keypair for ssh
authentication, generated by ssh_genkey (see ssh(1)).

Re: [9fans] cryptographic signatures & factotum

[David Presotto]

On Fri Mar 12 08:19:44 EST 2004, boyd@insultant.net wrote:
> > Yes, modulo my bugs in the security stuff.  Our password algorithm is
> > only DES.  Brute force would eventually work.  We should be moving to
> > a new alg.
> 
> http://plan9.bell-labs.com/magic/man2html/4/factotum
> 
> By default when factotum starts it looks for a secstore(1) account on $auth
> for the user and, if one exists, prompts for a secstore password in order to
> fetch the file factotum, which should contain control file commands. An
> example would be
> 
>       key dom=x.com proto=p9sk1 user=boyd !hex=26E522ADE2BBB2A229
>       key proto=rsa service=ssh size=1024 ek=3B !dk=...
> 
>   where the first line sets a password for challenge/response
> authentication, strong against dictionary attack by being a long random
> string, and the second line sets a public/private keypair for ssh
> authentication, generated by ssh_genkey (see ssh(1)).
> 

Yup, I figured everyone would want to be boyd.  If you are implying that we
already use a better algorithm, that's not really true for p9sk, only
for secstore.  If you are implying that we already have a better algorithm
implemented, you're right up to a point.

Re: [9fans] cryptographic signatures & factotum

[boyd, rounin]

> Yup, I figured everyone would want to be boyd.  If you are implying that
we
> already use a better algorithm, that's not really true for p9sk, only
> for secstore.  If you are implying that we already have a better algorithm
> implemented, you're right up to a point.

i'm implying that DES died 10+ years back.  i carried out the odd
'experiment' with some fast h/w and large amounts of disk [then].

DES unix password cracking came down to a grep of 4096
files, so a few seconds.  this was done for internal, sanctioned
[allowed] security issues.

i knew it was dead.  i just wanted to test it.  sadly, the
'experiment' was terminated, once it had proven its
point.

3DES is another issue.

Re: [9fans] cryptographic signatures & factotum

[John Kodis]

In article <028201c4083a$ac71c8c0$67844051@SOMA>, boyd, rounin wrote:

>  i'm implying that DES died 10+ years back.  i carried out the odd
>  'experiment' with some fast h/w and large amounts of disk [then].
>  DES unix password cracking came down to a grep of 4096 files, so a
>  few seconds.

Do you mean fast general-purpose hardware, or fast special-purpose
hardware?  Could you explain your general approach?

-- 
John Kodis                                    Goddard Space Flight Center
kodis@mail630.gsfc.nasa.gov                      Greenbelt, Maryland, USA
Phone: 301-286-7376                                     Fax: 301-286-1771

Re: [9fans] cryptographic signatures & factotum

[boyd, rounin]

> Do you mean fast general-purpose hardware, or fast special-purpose
> hardware?  Could you explain your general approach?

fast GP hardware meets brute force.

Re: [9fans] cryptographic signatures & factotum

[Nick Jamieson]

> My idea was to send just a plaintext email that contains two attachements.
> One being an rc script and the other an authenticating
> signature for that command. I think this is secure enough as the
> signature (hash) would need a shared secret to be validated.

Hi.

You should also include a time stamp to prevent replay attacks. Suppose you 
send [command, time, SHA1(command, secret, time)] to your work computer. Then 
your work computer can check that the digest is valid and that the time stamp 
is recent and not the same as a previously given time stamp. The work 
computer needs to remember each time stamp given for as long as it may be 
regarded as 'recent'.

Nick

Re: [9fans] cryptographic signatures & factotum

[boyd, rounin]

> You should also include a time stamp to prevent replay attacks. Suppose
you
> send [command, time, SHA1(command, secret, time)] to your work computer.

you mean a 'nonce'.  time is a really bad choice.

however, the SecureID cards used time, and it was explained to me
that they did it in a clever/secure way by mjr.

Re: [9fans] cryptographic signatures & factotum

[Nick Jamieson]

> you mean a 'nonce'.  time is a really bad choice.

Time is a really bad choice *if* there is the possibility that the 
current-time source(s) can be manipulated. In this case I don't think it will 
be a problem. If general nonces are used then the work computer would need to 
keep all of the given nonces forever to prevent replay attacks.

Trade offs...

Nick

Re: [9fans] cryptographic signatures & factotum

[boyd, rounin]

> Trade offs...

sure, that's what security is all about:

    - what you have to protect?
    - how much is it worth?
    - how much are you prepared to 'spend'?