I need to authenticate an unmanned system which can reboot at any
time.  I cannot use any hardware or pre-installed keys/certs.  Yes, I
know, there is no secure way of doing this.  

I am looking for another method, possibly an "Obscure" way of doing
this in a practical or very difficult to hack way.  

I do not want to invent anything.  

I think some combination of standard crypto/PBE/hash algorithms in
combination with a filesystem protected PKCS#12 key may be what I
need.  

Any help is appreciated

On Mon, 01 Sep 2003 21:08:36 -0400, Peter Gassman <peterg0000@aol.com>
wrote or quoted :

>I need to authenticate an unmanned system which can reboot at any
>time.  I cannot use any hardware or pre-installed keys/certs.  Yes, I
>know, there is no secure way of doing this. 

Just do you mean by that?

1. have the computer start up automatically after power is restored?
What OS are you using?

2. have the program start up automatically after power is restored?

3. have the program start up automatically after power is restored but
only if it was running at the time power was lost?

I will assume 3.  You want a back door to start the program that
bypasses the need for manual authentication.  In the simplest case it
could be a file you create on startup and delete on shutdown. If you
start and see the file, you bypass authentication.

OK, now what stops someone from counterfeiting that file? It could
contain an encrypted timestamp.  Even if someone manages to steal a
copy of the file, it is only good for a short while.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Tue, 02 Sep 2003 01:25:43 GMT, Roedy Green <roedy@mindprod.com>
wrote:

>On Mon, 01 Sep 2003 21:08:36 -0400, Peter Gassman <peterg0000@aol.com>
>wrote or quoted :
>
>>I need to authenticate an unmanned system which can reboot at any
>>time.  I cannot use any hardware or pre-installed keys/certs.  Yes, I
>>know, there is no secure way of doing this. 
>
>Just do you mean by that?

By authenticate I mean 
"Prove that you are who you say you are". 
In my simple minded way of thinking this means 
"Demonstrate that you are who you say you are by possessing a secret
and sending an encrypted message using that secret".

The problem is "How do I store and retrieve the secret in a secure
manner on an unmanned system"?


>
>1. have the computer start up automatically after power is restored?
>What OS are you using?
>
>2. have the program start up automatically after power is restored?
>
>3. have the program start up automatically after power is restored but
>only if it was running at the time power was lost?
>
>I will assume 3.  You want a back door to start the program that
>bypasses the need for manual authentication.  In the simplest case it
>could be a file you create on startup and delete on shutdown. If you
>start and see the file, you bypass authentication.
>
>OK, now what stops someone from counterfeiting that file? It could
>contain an encrypted timestamp.  Even if someone manages to steal a
>copy of the file, it is only good for a short while.

Not exactly what I need since I believe that you assume that at some
point the system was started with someone entering an authentication
token of some kind.  Your encrypted timestamp needs a key, right?

Thanks.

On Tue, 02 Sep 2003 07:33:43 -0400, Joh Doe <peterg0000@aol.com> wrote
or quoted :

>By authenticate I mean 
>"Prove that you are who you say you are". 
>In my simple minded way of thinking this means 
>"Demonstrate that you are who you say you are by possessing a secret
>and sending an encrypted message using that secret".
>
>The problem is "How do I store and retrieve the secret in a secure
>manner on an unmanned system"?

This sounds like a paradox. How can someone who is not there
authenticate who they are?  Do you mean a live human remotely
authenticate their identity?

Do you mean something simulates authenticating a real human? e.g. a
robot that types in the username and password. But if it does that, it
is not actually authenticating a human since somebody else or some
other process could trigger it. Maybe that does not matter. What you
really need is just a way to defeat a security system designed for a
manned installation.

Perhaps if you backed off a bit and described the context in which you
are having this problem it would be clearer to dolts like me what you
need to do.


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

"Peter Gassman" <peterg0000@aol.com> wrote in message
news:gcr7lvgtpnfqpev0rci3bv1rtn09u7kpat@4ax.com...
> I need to authenticate an unmanned system which can reboot at any
> time.  I cannot use any hardware or pre-installed keys/certs.  Yes, I
> know, there is no secure way of doing this.
>
> I am looking for another method, possibly an "Obscure" way of doing
> this in a practical or very difficult to hack way.
>
> I do not want to invent anything.
>
> I think some combination of standard crypto/PBE/hash algorithms in
> combination with a filesystem protected PKCS#12 key may be what I
> need.
>
> Any help is appreciated

I have to agree with Roedy Green that you need to explain the context more
for us to understand what you are looking for.

That said, I'll venture a guess at what you're asking. I think you are
saying this:
You have machine A and machine B
A needs to authenticate B. B is periodically restarted, and is unmanned.
You will write a program that runs on A and a program that runs on B. It is
through the functioning of these programs that A to authenticate B after
reboot.
You can not install a secret key on B, even though you are able to install
your program on B. (By this, I'm guessing that anything manually installed
on B for some reason can not be kept secret, and thus the constraint.)

Is this correct? If so, then I have to agree that in the most general case,
there is no secure way to do this the first time around. However, when B
starts up the first time, why not have A transfer some encrypted secret to
B, which in the future B will use to authenticate? Or does this violate your
constraints? Would this at least reduce the window during which B can be
impersonated to its first boot? You could then combine this with checking
the IP address to perhaps reduce the risk a little further (although IP
addresses can be forged.)

If this does not meet your constraints, then perhaps you could clarify
exactly what your constraints are and what you have to work with.

Ben

Your interpretation of my poorly worded requirements is absolutely
correct.  
I agree with your conclusion and your solution is intriguing.  Thank
you.  
That said, any other good ideas???

On Mon, 8 Sep 2003 12:40:19 -0400, "Ben Mord" <benmord@earthlink.net>
wrote:

>
>"Peter Gassman" <peterg0000@aol.com> wrote in message
>news:gcr7lvgtpnfqpev0rci3bv1rtn09u7kpat@4ax.com...
>> I need to authenticate an unmanned system which can reboot at any
>> time.  I cannot use any hardware or pre-installed keys/certs.  Yes, I
>> know, there is no secure way of doing this.
>>
>> I am looking for another method, possibly an "Obscure" way of doing
>> this in a practical or very difficult to hack way.
>>
>> I do not want to invent anything.
>>
>> I think some combination of standard crypto/PBE/hash algorithms in
>> combination with a filesystem protected PKCS#12 key may be what I
>> need.
>>
>> Any help is appreciated
>
>I have to agree with Roedy Green that you need to explain the context more
>for us to understand what you are looking for.
>
>That said, I'll venture a guess at what you're asking. I think you are
>saying this:
>You have machine A and machine B
>A needs to authenticate B. B is periodically restarted, and is unmanned.
>You will write a program that runs on A and a program that runs on B. It is
>through the functioning of these programs that A to authenticate B after
>reboot.
>You can not install a secret key on B, even though you are able to install
>your program on B. (By this, I'm guessing that anything manually installed
>on B for some reason can not be kept secret, and thus the constraint.)
>
>Is this correct? If so, then I have to agree that in the most general case,
>there is no secure way to do this the first time around. However, when B
>starts up the first time, why not have A transfer some encrypted secret to
>B, which in the future B will use to authenticate? Or does this violate your
>constraints? Would this at least reduce the window during which B can be
>impersonated to its first boot? You could then combine this with checking
>the IP address to perhaps reduce the risk a little further (although IP
>addresses can be forged.)
>
>If this does not meet your constraints, then perhaps you could clarify
>exactly what your constraints are and what you have to work with.
>
>Ben
>

Your interpretation of my poorly worded requirements is absolutely
correct.  
I agree with your conclusion and your solution is intriguing.  Thank
you.  
That said, any other good ideas???

On Mon, 8 Sep 2003 12:40:19 -0400, "Ben Mord" <benmord@earthlink.net>
wrote:

>
>"Peter Gassman" <peterg0000@aol.com> wrote in message
>news:gcr7lvgtpnfqpev0rci3bv1rtn09u7kpat@4ax.com...
>> I need to authenticate an unmanned system which can reboot at any
>> time.  I cannot use any hardware or pre-installed keys/certs.  Yes, I
>> know, there is no secure way of doing this.
>>
>> I am looking for another method, possibly an "Obscure" way of doing
>> this in a practical or very difficult to hack way.
>>
>> I do not want to invent anything.
>>
>> I think some combination of standard crypto/PBE/hash algorithms in
>> combination with a filesystem protected PKCS#12 key may be what I
>> need.
>>
>> Any help is appreciated
>
>I have to agree with Roedy Green that you need to explain the context more
>for us to understand what you are looking for.
>
>That said, I'll venture a guess at what you're asking. I think you are
>saying this:
>You have machine A and machine B
>A needs to authenticate B. B is periodically restarted, and is unmanned.
>You will write a program that runs on A and a program that runs on B. It is
>through the functioning of these programs that A to authenticate B after
>reboot.
>You can not install a secret key on B, even though you are able to install
>your program on B. (By this, I'm guessing that anything manually installed
>on B for some reason can not be kept secret, and thus the constraint.)
>
>Is this correct? If so, then I have to agree that in the most general case,
>there is no secure way to do this the first time around. However, when B
>starts up the first time, why not have A transfer some encrypted secret to
>B, which in the future B will use to authenticate? Or does this violate your
>constraints? Would this at least reduce the window during which B can be
>impersonated to its first boot? You could then combine this with checking
>the IP address to perhaps reduce the risk a little further (although IP
>addresses can be forged.)
>
>If this does not meet your constraints, then perhaps you could clarify
>exactly what your constraints are and what you have to work with.
>
>Ben
>

On Mon, 8 Sep 2003 12:40:19 -0400, "Ben Mord" <benmord@earthlink.net>
wrote or quoted :

>A needs to authenticate B. B is periodically restarted, and is unmanned.
>You will write a program that runs on A and a program that runs on B. It is
>through the functioning of these programs that A to authenticate B after
>reboot.

Machine B is presumably physically secure.  Otherwise, you could just
copy the disk of machine B and run the software on machine C to spoof
being machine C.  Correct?

You are attempting to prove that machine B logging in to machine A
truly is machine B, so long no one has had physical access to machine
B.

B has to have a secret that no one else knows, typically a private
key. A then sends a random challenge phrase to B. B encrypts it with
the private key and sends it back. A decrypts it with B's public key.
If it matches, it must be B.  In other words, B digitally signed a
document provided by A to prove its identity.  It parallels how you
can establish identity at a bank with just your signature.

See http://mindprod.com/jgloss/digitalsignatures.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Thu, 11 Sep 2003 20:55:39 GMT, Roedy Green <roedy@mindprod.com>
wrote:

>On Mon, 8 Sep 2003 12:40:19 -0400, "Ben Mord" <benmord@earthlink.net>
>wrote or quoted :
>
>>A needs to authenticate B. B is periodically restarted, and is unmanned.
>>You will write a program that runs on A and a program that runs on B. It is
>>through the functioning of these programs that A to authenticate B after
>>reboot.
>
>Machine B is presumably physically secure.  Otherwise, you could just
>copy the disk of machine B and run the software on machine C to spoof
>being machine C.  Correct?

Yes, it is physically secure but, it is on a network, possibly a
public network.

>
>You are attempting to prove that machine B logging in to machine A
>truly is machine B, so long no one has had physical access to machine
>B.
>
>B has to have a secret that no one else knows, typically a private
>key. 

This is a standard solution but, the problem with taking this tack is:
How does B securely store the secret so that on a restart the program
running on B can use it without human intervention?  A crypto card
with secure key storage is an option.

Thanks.
A then sends a random challenge phrase to B. B encrypts it with
>the private key and sends it back. A decrypts it with B's public key.
>If it matches, it must be B.  In other words, B digitally signed a
>document provided by A to prove its identity.  It parallels how you
>can establish identity at a bank with just your signature.
>
>See http://mindprod.com/jgloss/digitalsignatures.html

On Fri, 12 Sep 2003 09:11:15 -0400, Peter Gassman <peterg0000@aol.com>
wrote or quoted :

>This is a standard solution but, the problem with taking this tack is:
>How does B securely store the secret so that on a restart the program
>running on B can use it without human intervention?  A crypto card
>with secure key storage is an option.



Obviously anyone with physical access to the machine can steal the
secret.

Any hacker that can break in and steal the program in total can steal
the secret.

Any clever hacker can replace your program with a modified one,
including its ability to access special hardware.

You can protect the secret from prying eyes by doubly encrypting it,
but obviously the tools for decrypting it must either be lying around
the machine somewhere, or must come from the some other machine at the
last minute.

You have to think just what sort of attack you are trying to protect
against.  To what lengths are your enemies likely prepared to go to
crack this?

Even if the server sends decrypting information at the last second,
they would presumably send it also to any spoofer.

It is easiest to lock out folk who have no physical access to the real
computer B.

Once they can corrupt software in B, all security is gone.

People tend to build these Maginot lines. Of course hackers look for
ways around them rather than through them.

Are you allowed to tell us roughly what this machine B does?

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.