Hello All,

First, I would like to thank Giuliano for the advice.

Here is what I have come up with. I am hoping to get some good
feedback either positive or negative regarding this approach.

The file server makes use of an encryption key that is shared with the
clients. The shared encryption key is used to calculate the current
server password, which changes periodically.

A relational database is used to store user account information and
encryption keys. The keys are encrypted with the Key store encryption
key and Base64 encoded before being inserted into the database. The
database server is running on different hardware and has good network
and physical security.

There are three user roles:

1. File upload
2. File download
3. User management

Each user is assigned a USB smart key

Each USB smart key contains two encryption keys. The type and purpose
of these keys varies by role.

1. File Upload - File encryption key, Server password calculation key
2. File Download - Key store encryption key, Server password
calculation key.
3. User management - Key store encryption key, Server password
calculation key.


File upload

1. The file encryption key is retrieved from the USB smart key. The
upload file is hashed, encrypted, and compressed.
2. The file server password calculation key is retrieved from the USB
smart key and used to calculate the current file server password.
3. The password is calculated and login occurs.
4. The file is uploaded.

File download

1. The file server password calculation key is retrieved from the USB
smart key and used to calculate the current file server password.
2. The password is calculated and login occurs.
3. A file is selected for download.
4. The selected file is downloaded.
4. The user account record for the user who uploaded the file is
retreived from the database.
5. The key store encryption key is retrieved from the USB smart key.
6. The file encryption key is decrypted.
7. The  file is uncompressed,  decrypted, verified, and processed

Note: Periodic key changes occur and are handled similar to the file
upload/download scenario.

This is not a complete and detailed picture, but it should be enough
to represent the approach. Any thoughts or advice on this would be
very welcome.

Thanks,
Gerry




















On Apr 20, 2:57 am, Giuliano Bertoletti <[email protected]> wrote:
> Hello,
>
> first you should check which algorithms the smart card can use with that
> key.
> You mention a 32-bit key, so I presume this is a symmetric based
> encryption with algorithms such as AES.
>
> If so, one possible solution is to:
>
> 1) have the server enroll each new smartcard by imprinting a random
> known key into the device and holding a copy on it own. You should also
> need a way to label the smart card in order to bind a name with an
> encryption key.
>
> 2) have the server publish each day the next new password on a
> fileserver, encrypted with each smart card key. Basically you have n
> smart cards, n keys and, then n different encrypted blobs, each one
> decryping to the same daily password.
>
> 3) have each client retrieve its encrypted blob, decrypt it and recover
> the password.
>
> You cannot bypass the comminication step (server that publishes
> encrypted information for clients) because clients are not sharing a
> common secret which you might use to derive password from.
>
> Regards,
> Giuliano Bertoletti
>
> Gerry Weaver ha scritto:
>
> > Hello All,
>
> > I need some good advice on how to approach a problem that I currently
> > need to solve. Firstly, I am not well versed in cryptography in
> > general. I hope y'all will be gentle with what may be a foolish idea.
>
> > Anyway...
>
> > I've got a situation where I need to deal with a single server account
> > shared between several client applications. The ability to create and
> > manage separate user accounts is not an option. I am considering an
> > approach that would have the server change the "common" account
> > password via a daily cron job. I would like to come up with a
> > reasonably secure way for the client application to derive/anticipate
> > the daily password through some type of cryptographic calculation.
> > Each client does make use of a USB smart card type device with a
> > 32byte encryption key stored as a hex string. However, each key is
> > unique to each client. It would be very cool if there were a way to
> > derive the daily password through some type of calculation utilizing
> > that key. I do have the ability to change the client key. I got the
> > basic idea from reading about using RSA etc. for software activation
> > keys.
>
> > Any help or advice on this would be very much appreciated. I certainly
> > don't have anywhere near the necessary crypto experience to devise a
> > secure solution.
>
> > Thanks in advance,
> > Gerry
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---

Reply via email to