SmartSession HOWTO
------------------
Vincent Guerin <vincent.guerin@gemplus.com>
Ludovic Rousseau <ludovic.rousseau@gemplus.com>
2.2 1 février 2001
-------------------------------------------------------------------------------
Résumé
------
This document describes how to use the SmartSession suite. This set
of tools provides functions and modules able to secure a Linux session
using smartcards (login, autolock, ciphered file system).
-------------------------------------------------------------------------------
Table des matières
------------------
1. WHAT IS SMARTSESSION?
2. WHAT CARDS ARE USED?
3. SMARTSESSION FOR THE IMPATIENT
3.1. About the pam_smartcard module
3.2. About CFS for smartcard
4. HOW TO MANAGE THE SMARTCARDS
4.1. Choose a passphrase
4.2. Format a smartcard
4.3. Change the user PIN
4.4. Unlock a smartcard
4.5. Life cycle of the smartcard
5. HOW TO MANAGE THE PUBLIC KEY CERTIFICATION
5.1. What is the public key certification
5.2. Create the administrator certification smartcard
5.3. Install the certification public key
5.4. Other feature of the certification
6. HOW TO MANAGE THE USER PUBLIC KEYS
6.1. Using a local database
6.2. Using NIS
6.3. Add a new user
6.4. Delete a registered user
6.5. List the registered user
6.6. Verify the database integrity
7. HOW TO USE THE PAM_SMARTCARD MODULE
8. HOW TO INTEGRATE THE PAM_SMARTCARD MODULE IN VARIOUS
APPLICATIONS
8.1. In the console login application
8.2. In login with display manager applications
8.3. In other authentication applications
9. HOW TO USE THE CFS FOR SMARTCARD APPLICATION
10. HOW RESTORE A CFS CIPHERED DIRECTORY
11. FOCUS ON THE AUTOLOCK DAEMON
11.1. What is the autolock demon
11.2. Some particularities
11.3. When the card is in the reader
11.4. When the card is removed from the reader
12. FOCUS ON THE SMATCARD FILE STRUCTURE
12.1. User card
12.2. Admin card
-------------------------------------------------------------------------------
1. WHAT IS SMARTSESSION?
------------------------
SmartSession is a set of binaries and modules able to secure a Linux
session using smartcards.
It can:
1. secure the account access by providing a PAM module that allows
to:
1. authenticate users using their smartcards (auth part). This
feature can work locally and with NIS (like the UNIX
password mechanism);
2. lock the computer when the smartcard is removed (session
part).
2. cipher files and directories by providing a set of functions that
wrap the corresponding CFS (Ciphered File System) functions in
order to use the smartcard to store the CFS secret passphrase. A
PAM module (session part) is also provided in order to
automatically manage the attachment/detachment of the ciphered
directories during the login/logout.
It also provides some administration tools able to manage the card and
the mechanism user database.
See `smartsession'(5) for more details.
It can be downloaded from
`http://www.gemplus.fr/developers/technologies/'
-------------------------------------------------------------------------------
2. WHAT CARDS ARE USED?
-----------------------
The cards used are the GEMPLUS GPK cards: GPK 4000, 8000, 16000.
Warning, the system key of these cards must be the sample key: <TEST
KEYTEST KEY>. It's not a security problem but the application doesn't
work with cards initialized with the secure process.
-------------------------------------------------------------------------------
3. SMARTSESSION FOR THE IMPATIENT
---------------------------------
3.1. About the pam_smartcard module
-----------------------------------
This part explains simply how to start with `pam_smartcard'(5). You
will create the administrator certification smartcard and a user
authentication smartcard. This user will be able to locally log in
with his smartcard
To start, you have to modify the PAM configuration file of the
different login application in order to use the `pam_smartcard'
module. You should just test it using the `login' application that
manages login for non-graphical virtual console.
To use the smartcard authentication module in addition of the password
authentication you could patch `/etc/pam.d/login' with
`/usr/share/doc/smartsession/Tools/login.patch'. The user will be
firstly prompted for his smartcard, if he doesn't have an
authentication card, he could be logged in with his password. The
autolock daemon is also started, It will lock the virtual consoles if
the card is removed from the reader.
It also exists a patch for the display manager in order to have the
same new features: `/usr/share/doc/smartsession/Tools/gdm.patch'
To operate on the smartcard, you can choose between two tools:
`sst'(8) is a command line tool and `xsst'(8) is a graphical tool.
You can also use a sample script to create your first cards.
In any case, you must choose a passphrase between 8 and 64 characters
(See Section 4.1, `Choose a passphrase').
3.1.1. Using the sample script
------------------------------
You can simply choose to be guided by a sample script that can be
found in `/usr/share/doc/smartsession/Tools/script_test'.
This script is based on the `sst' functions and executes the next
procedure.
More, you can use the `/usr/share/doc/smartsession/Tools/erase_gpk8k'
script to erase the smartcards. Warning, it erases all the content of
the smartcard, not just the smartsession part.
3.1.2. Using `sst'(8)
---------------------
If you want to work with `sst'(8), the passphrase will be given at
each call to the sst functions.
Now, just follow this step by step procedure:
1. Create the administrator certification card:
sst create_cert_card -p <passphrase>
2. Install the certification card on the computer:
sst install_cert_card -p <passphrase>
3. Format the user authentication card:
sst format_card -p <passphrase>
4. Set the user PIN code
sst unlock_card -p <passphrase> -c <pin>
5. Add the new user in the default database
sst add_user -p <passphrase> -u <username>
-d default
You will be prompted for the certification card. Enter this card
and press Enter.
6. To verify that the user is well registered:
sst list_user -p <passphrase> -d default
3.1.3. Using `xsst'(8)
----------------------
If you want to work with `xsst'(8) you have to give the passphrase one
time in the start window. You don't have to change anything in the
public key destination section, the used database is the default
database: `/etc/smartsession/smartpamkey.dbm'.
After having clicked on OK you will access to the main window.
Now, just follow this step by step procedure:
1. Create the administrator certification card: Click on the OK
button in the Create administrator certification card of the
Manage Certification page.
2. Install the certification card on the computer: Click on the OK
button in the Install certification public key of the Manage
Certification page
3. Format the user authentication card: Click on the Format button
in the Manage Card page
4. Set the user PIN code: Enter the PIN code twice in the boxes of
the Change PIN / Unlock card section of the Manage Card page.
Click on the OK button.
5. Add the new user in the default database: In the Manage Users
page, give the user name in the box and click on the Create
button. You will be prompted for the certification card. Enter
this card and click OK.
6. To verify that the user is well registered: Just look at the
registered user window in the Manage Users page.
3.2. About CFS for smartcard
----------------------------
We assume that the user has a formatted SmartSession card (See Section
4.2, `Format a smartcard'). It's not necessary to have installed the
user in a database or to have a certification card; a formatted card
is sufficient.
Now, just follow this step by step sample:
1. Create a ciphered directory called `top_secret':
cmkdir_SC top_secret
You will be asked for your PIN code and the directory will be
created in the current directory.
2. Attach the created ciphered directory to `top_clear':
cattach_SC top_secret top_clear
You will be asked for your PIN code the clear content of this
directory will be available on `/crypt/top_clear'. Now, in this
directory, you can create other files or directory that will be
ciphered in `top_secret'.
3. Detach the directory `top_clear':
cdetach_SC top_clear
The clear version of `top_secret' is no longer available.
4. If you want to remove the ciphered directory `top_secret', simply
use the `rm' command.
-------------------------------------------------------------------------------
4. HOW TO MANAGE THE SMARTCARDS
-------------------------------
4.1. Choose a passphrase
------------------------
The administrator must choose and retain a passphrase. This
passphrase is at the root of the mechanism security because it will be
used to generate the administrator PIN and PUC codes in the user
smartcards. So, this passphrase must be sufficiently diversified and
it size must be between 16 and 64 characters.
4.2. Format a smartcard
-----------------------
It's necessary to format the smartcard for the smartsession
applications. During this operation the authentication key will be
generated (by the smartcard) and a random CFS secret will be stored in
the smartcard. The different codes will be also generated and store.
After the formatting operation the user PIN code is set to a default
value _0000_. The owner of this smartcard must obviously change this
PIN to a personal value.
Use the _Format_ function of your favourite SmartSession Tool.
4.3. Change the user PIN
------------------------
If the user has forgotten his PIN code, the administrator, using the
_Change PIN - Unlock Card_ must attribute a new PIN code.
If the user just wants to have a new PIN code, knowing the current
one, he can do it himself using the `chpin'(1) binary.
Four digits constitute the user PIN code.
4.4. Unlock a smartcard
-----------------------
By default, the user has up to three tries to give his correct PIN
code. If he fails, the smartcard is blocked and becomes unusable for
the smartsession applications. The administrator can unlock this
smartcard using the _Change PIN - Unlock Card_ function of a
SmartSession Tool. During this operation, the user is asked for a new
PIN code.
Four digits constitute the user PIN code.
4.5. Life cycle of the smartcard
--------------------------------
A formatted smartcard will be attributed to a user (See Section 6.3,
`Add a new user'). If this user doesn't have to use the system
anymore, he gives back his smartcard to the administrator. Now, he
can delete this user from the databases where he could be registered
(See Section 6.4, `Delete a registered user').
The smartcard can be reattributed to another user.
The smartcard cannot be reformatted, so the public key corresponding
to this smartcard is the same during all the life of the smartcard.
-------------------------------------------------------------------------------
5. HOW TO MANAGE THE PUBLIC KEY CERTIFICATION
---------------------------------------------
5.1. What is the public key certification
-----------------------------------------
The user public keys are shared by NIS and this mechanism is not fully
secure. In fact, a hacker can pass himself off as the NIS server and
sends his public key to the authentication module. This hacker will
be logged in without having a registered public key in the system
To circumvent this security hole, the administrator signs the
registered user public keys and the module verifies the signature of
the got key. Now, the hacker will be unable to sign his public key
himself...
This mechanism requires two things:
1. the administrator must have a certification smartcard to sign the
user public keys;
2. a certification public key must be copied securely on each
computer. This key will be used to verify the user public key
signature.
5.2. Create the administrator certification smartcard
-----------------------------------------------------
It must be done before use the system because this smartcard is
necessary to register the users.
Just use a blank smartcard and the _Create certification card_
function of a SmartSession Tool. This operation required the
previously chosen passphrase. The use of this smartcard is obviously
protected by a PIN code but this code is automatically generated using
the passphrase.
5.3. Install the certification public key
-----------------------------------------
Initially this key is stored on the certification smartcard. There
are two ways to install this key on a computer:
1. Install the key from the smartcard to the computer using the
_Install certification key_ function of a SmartSession Tool.
This operation requires to insert the certification smartcard on
each computer. It also required the passphrase
2. Install the key one times on a computer and use a secure
mechanism (like _scp_(1)) to manually copy the key on each
computer. The key is and must be stored in
_/etc/smartsession/pam_CA_key_
5.4. Other feature of the certification
---------------------------------------
In fact, the administrator certification contains a second private key
that is used to restore the CFS secret for user having lost their
smartcard.
The secret used to cipher a CFS directory is ciphered with the public
key corresponding to this second key and store in the directory. To
restore this secret, the administrator have to use his certification
smartcard in order to decrypt it. See Chapitre 10, `HOW RESTORE A CFS
CIPHERED DIRECTORY'.
-------------------------------------------------------------------------------
6. HOW TO MANAGE THE USER PUBLIC KEYS
-------------------------------------
The user public keys can be registered on the system using a local
database (like the _/etc/passwd/_ file) or can be share through a
network using NIS.
First, we will see the specificity of these two possibilities and next
we will learn how manage the users of the smartpam authentication
mechanism.
6.1. Using a local database
---------------------------
This database must be created on each computer. By default the
`/etc/smartsession/smartpamkey.dbm' is used. It also possible to use
other local databases by given their names in option of the different
commands. This name must be suffixed by the `.dbm' extension.
A database of local users can be created on a computer and, next, can
be copied to another using a secure mechanism (like _scp_(1)).
6.2. Using NIS
--------------
6.2.1. Modify the NIS server configuration file
-----------------------------------------------
This part required a little work. It's necessary to modify the
`Makefile' on the NIS server to add the new user public keys map.
So you must patch `/var/yp/Makefile' with:
--- Makefile Mon Nov 13 13:30:06 2000
+++ Makefile-patched Mon Nov 13 13:40:38 2000
@@ -61,6 +61,7 @@
# these to taste in the event that you wish to keep your NIS source files
# seperate from your NIS server's actual configuration files.
#
+SMARTPAMKEY = $(YPSRCDIR)/smartsession/smartpamkey
GROUP = $(YPPWDDIR)/group
PASSWD = $(YPPWDDIR)/passwd
SHADOW = $(YPPWDDIR)/shadow
@@ -98,7 +99,8 @@
# If you don't want some of these maps built, feel free to comment
# them out from this list.
-all: passwd group hosts rpc services netid protocols netgrp networks \
+all: smartpamkey \
+ passwd group hosts rpc services netid protocols netgrp networks \
# shadow publickey mail ethers bootparams printcap \
# amd.home auto.master auto.home auto.local passwd.adjunct \
# timezone locale netmasks
@@ -136,6 +138,7 @@
timezone: timezone.byname
locale: locale.byname
netmasks: netmasks.byaddr
+smartpamkey: smartpamkey.byname
ypservers: $(YPSERVERS) $(YPDIR)/Makefile
@echo "Updating $@..."
@@ -458,3 +461,10 @@
print $$1"\t"$$2 }' $(NETMASKS) | $(DBLOAD) \
-r -i $(NETMASKS) -o $(YPMAPDIR)/$@ - $@
-@$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
+
+smartpamkey.byname: $(SMARTPAMKEY) $(YPDIR)/Makefile
+ @echo "Updating $@..."
+ @$(AWK) '{ if($$1 !~ "#" && $$1 != "") { print $$1"\t"$$2 }}' \
+ $(SMARTPAMKEY) | $(DBLOAD) -i $(SMARTPAMKEY) \
+ -o $(YPMAPDIR)/$@ - $@
+ @$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
This patch can also be found in
`/usr/share/doc/smartsession/Makefile.patch'.
If you use NIS slaves, do not forget to edit
`/usr/lib/yp/ypxfr_1perhour' or equivalent.
Extract from `/usr/doc/nis/nis.debian.howto.gz'
You might want to put the following script fragment into
`/etc/cron.d/nis' *on the slave*, and make `/etc/cron.d/nis'
executable (`chmod 755 /etc/cron.d/nis') :
20 * * * * root /usr/lib/yp/ypxfr_1perhour >/dev/null 2>&1
40 6 * * * root /usr/lib/yp/ypxfr_1perday >/dev/null 2>&1
55 6,18 * * * root /usr/lib/yp/ypxfr_2perday >/dev/null 2>&1
This will ensure that most NIS maps are kept up-to-date, even if an
update is missed because the slave was down at the time the update was
done on the master.
6.2.2. Use the mechanism
------------------------
We must operate manually to update the NIS server:
A text file corresponding to each dbm database is automatically
created. The name of this file is the name of the dbm database
without the `.dbm' extension. This file will be used to update the
NIS server.
You have to choose a dbm database used as a reference database for
NIS. You can manage this database using `xsst'(1) or `sst'(1), like
local databases to add or delete users.
After any modification, you have to copy the corresponding text file
on the `/etc/smartsession/' directory on the NIS server and run its
`Makefile' to update the NIS map `smartpamkey.byname'.
To keep the NIS mechanism consistency, you should always use the same
reference database.
Warning, the text files shouldn't be manually modified. That's why
the text file has not the write attribute. Only Work on the dbm
databases using the smartsession tools.
6.3. Add a new user
-------------------
To add a new user in a database, use the _Add user_ function of a
SmartSession Tool.
This operation required the smartcard (that will be attributed to this
new user), the passphrase and the administrator certification
smartcard. During this operation:
1. the name of the user is stored on the smartcard;
2. the user public key stored on the smartcard is signed with the
certification smartcard and stored in the specified database;
In fact, the smartcard could be already attributed to the user. For
example, the user is registered in a local database and wants to be
registered by NIS.
Concerning the user public key certification, it's possible to enable
the two readers option in the SmartSession Tool. In this case the
user smartcard will be inserted in the reader connected to
`/dev/screader' and the certification will be inserted in the second
reader connected to `/dev/screader1'.
It's perhaps necessary to explain that these are links on the serial
ports where are connected the readers. By default the first link it
always created during the installation of the reader driver library,
but the second link must be created manually. So, for example, if the
second reader is connected on the serial number 2, you should create:
ln -s /dev/ttyS1 /dev/screader1
The two readers feature is convenient to add numerous users. It
avoids manipulating the certification smartcard that remain in its
dedicated reader during the operations.
6.4. Delete a registered user
-----------------------------
To delete a new user in a database, use the _Delete user_ function of
a SmartSession Tool.
This operation just required being root. The user public key is
simply removed from the specified database.
The smartcard of the user to delete is not necessary to this
operation.
6.5. List the registered user
-----------------------------
To list the users registered on the database, use the _List user_
function of a SmartSession Tool.
6.6. Verify the database integrity
----------------------------------
The _Verify database_ function of X SmartSession Tool (`xspt'(8))
allows to verifying that all the public keys registered on a database
are different. It's a strong constraint of integrity. If a public
key is duplicated it's probably caused by the reuse of a smartcard
without have deleted its previous owner. It could be a security
hole...
-------------------------------------------------------------------------------
7. HOW TO USE THE PAM_SMARTCARD MODULE
--------------------------------------
See `pam_smartcard'(5)
-------------------------------------------------------------------------------
8. HOW TO INTEGRATE THE PAM_SMARTCARD MODULE IN VARIOUS APPLICATIONS
--------------------------------------------------------------------
8.1. In the console login application
-------------------------------------
Concerning the authentication part, you could simply use the module by
adding it in the PAM configuration file of `login'(1) for the _auth_.
Concerning the session part (the autolock daemon) it's necessary to
enable the close session option in `/etc/login.defs':
CLOSE_SESSIONS yes
Otherwise the login application doesn't call the PAM close session
modules at the end of the session and so doesn't kill the autolock
daemon.
Now, you could add the module in the PAM configuration file of
`login'(1) for the _session_.
8.2. In login with display manager applications
-----------------------------------------------
This module can be used with different display managers by some
constraints or restrictions can be found. This is not inherent in the
module but caused by the applications that not fully respect the PAM
requirements.
8.2.1. With `gdm'
-----------------
The module is perfectly integrated. The release 2.0 `gdm'(1)
perfectly respects the PAM requirement and asks the user for all the
information required by the modules.
So, I advise you for this one.
8.2.2. With `kdm'
-----------------
The `kdm'(1) display manager doesn't respect the request of the
modules and always ask the user for two thing: his username and his
password.
If the module is used instead of the password authentication module,
user should enter his PIN code in the box named password. It's not a
serious problem. If the module is use with the password
authentication module or with modules requiring other information, the
mechanism doesn't work because only one information (PIN or password)
can be given.
8.2.3. With `xdm'
-----------------
It's the same problems as `kdm'.
8.3. In other authentication applications
-----------------------------------------
This module could also be used in all the applications dedicating
their user authentication part to PAM. For example in various screen
lockers like `xlock'(1), `lockvc'(1) but also in applications such
`su'(1) or `sudo'(8)...
You have just to add the module in the application PAM configuration
file. You can choose to use the same user databases as for the login
or another local database.
This module cannot be used in remote application such `ftp' because
the smartcard must be inserted in the reader connected to the computer
on which the authentication is carried out.
The session part of this module doesn't have interest for other
applications than login applications.
-------------------------------------------------------------------------------
9. HOW TO USE THE CFS FOR SMARTCARD APPLICATION
-----------------------------------------------
`CFS' (Ciphered File Directory) is an application that allows
ciphering directories. Each directory is created using `cmkdir'(1).
They can be attached using `cattach'(1). It means that the user may
access the cleartext of the files in a virtual directory under the CFS
mount point (usually /crypt). To remove the clear version of the
directory the command is `cattach'(1). These binaries required that
the user choose a long passphrase associated with each created
directory.
The idea of the CFS for smartcard application is to store the
passphrase in the smartcard. So the three original functions are
wrapped by three functions: `cmkdir_SC'(1), `cattach_SC'(1),
`cdetach_SC'(1).
These functions also use two files in order to automate the attachment
and detachment operation. See their man pages for more details.
Concerning the smartcard, the CFS passphrase, called the CFS secret,
is generated during the smartcard format operation and is the same
during all the life of the smartcard. So the administrator have
nothing to do after having formatted the smartcard.
It also provided a PAM module (session part) which can automatically
attach (resp. detach) ciphered directory during login (resp.
logout). See `pam_cfs_SC'(5).
-------------------------------------------------------------------------------
10. HOW RESTORE A CFS CIPHERED DIRECTORY
----------------------------------------
If a user brakes or looses his smart card, he can't decipher his CFS
ciphered directories. To restore this directories, the secret used to
cipher they is ciphered with `CFS_deposite_key' and stored in each
ciphered directory. To restore this secret, the administrator have to
use his certification smartcard and the `crescue_SC'(1) function.
Suppose that the user has lost his smartcard and want to restore the
ciphered directory `top_secure'. The administrator have to restore
the secret used to cipher this directory:
crescue_SC top_secure
The secret is now available in `restored_secret'. To restored the
data, the user has to use the `cattach'(1) function with this restored
secret:
cattach top_secure top_secure_restore -- < restored_secret
The clear data will be available in `/crypt/top_secure_clear'. To
re-cipher this directory with the new user card, the user must create
a new CFS ciphered directory (using `cmkdir_SC'(1) with his new card),
attach it (using `cattach_SC'(1) and recursively copy the restore data
on the attached new directory:
cmkdir_SC top_secure_new
cattach top_secure_new top_secure_new_clear
cp -r top_secure_restore top_secure_new_clear
cdetach top_secure_restore
cdetach_SC top_secure_new_clear
rm -fr top_secure
Now the CFS `directory top_secure' (ciphered with the lost card) is
tranfered in the CFS directory `top_secure_new' (ciphered with the new
card).
Note that this mechanism is also available if the administrator have a
certification card (See Chapitre 5, `HOW TO MANAGE THE PUBLIC KEY
CERTIFICATION') and if the `CFS_deposite_key' was installed on the
computer.
-------------------------------------------------------------------------------
11. FOCUS ON THE AUTOLOCK DAEMON
--------------------------------
11.1. What is the autolock demon
--------------------------------
The autolock daemon is executed by the session management group of the
`pam_smartcard' module. It's a daemon that continuously tests the
presence of the authenticated user card on the reader. If the user
removes his card, the daemon locks all the virtual consoles using
`smartlocker'(1). By default the consoles are unlocked only if the
user re-inserts his smartcard on the reader and re-gives his right PIN
code.
It's possible, on a computer, to exclude some users from this
mechanism. These users must be registred in the
`/etc/smartsession/autolock_excluded' file; one user per line.
The autolock daemon is started when the user opens his first console;
it is stopped when he closes the last one. To register the opened
session, it uses the `/var/run/autolock.pid'. In this file, the first
pid corresponds to the autolock daemon itself.
If the autolock daemon mechanism is available on the computer only ONE
user can be physically logged to one or several consoles of the
computer.
To suspend the daemon, for example, if you want to use the reader for
another application, see `autolock_ctrl'(1).
Actually autolock is not fully compatible with `vmware'(1). In fact
it won't work if the card is removed when `vmware' is running in full
screen mode; it's generaly on the virtual console number 8. To
circumvent this problem, swith on another console before removing the
smartcard. If you have removed the smartcard while `vmware' was in
full screen mode, autolock is in a blocked state. To restart it,
switch on the first free virtual console; it should be the console
number 9.
11.2. Some particularities
--------------------------
The use of the `autolock' daemon could induce the call off numerous
processes and particularly when the virtual consoles become locked.
In can be a good idea to show what are the binaries called and the
tree of these calls.
11.3. When the card is in the reader
------------------------------------
You can see that the `autolock' daemon is a child of the `init'
process. `autolock' is launched by `login' (`login' can be replace in
the same way by `xdm', `kdm', `gdm'...) then forks to become a daemon.
The four arguments of the `autolock' process are the name of the
action, the name of the owner of the card, the card serial number and
the pid of the first session which caused it's execution. `autolock'
continuously verify that the number of the card in the reader is the
same as the number received in argument (which is the number of the
authenticated card).
You can also see that the daemon runs with the user right.
init(1)
|...
|-login(439,rousseau) --
| `-bash(12797)
|-autolock(12791,rousseau) add_session rousseau 144b1947702e0915 439
|...
11.4. When the card is removed from the reader
----------------------------------------------
When the card is removed from the reader, `autolock' must lock the
virtual consoles using `smartlocker'. It is not possible to directly
execute `smartlocker' because it will not work if we are currently in
the X virtual console.
So we must switch on the first free text virtual console before run
`smartlocker'. Is for reason that we call `openvt'.
For it's own needs, `openvt' forks in a second `openvt'.
init(1)
|...
|-login(439,rousseau) --
| `-bash(12797)
|-autolock(12791,rousseau) add_session rousseau 144b1947702e0915 439
| `-openvt(12824) -s -w -- /usr/sbin/smartlocker
| `-openvt(12825) -s -w -- /usr/sbin/smartlocker
| `-smartlocker(12826)
|...
-------------------------------------------------------------------------------
12. FOCUS ON THE SMATCARD FILE STRUCTURE
----------------------------------------
12.1. User card
---------------
3F00 MF
|
|- 0500 DF SmartSession application
| |
| |- 0501 EF Secret Codes
| |- 0502 EF User Name
| |- 0503 EF Authentication RSA key
| |- 0504 EF CFS Secret
|
12.2. Admin card
----------------
3F00 MF
|
|- 0600 DF SmartSession application
| |
| |- 0601 EF Secret Codes
| |- 0602 EF Certification RSA key
| |- 0603 EF Restauration RSA key
|
-------------------------------------------------------------------------------
SmartSession HOWTO
Vincent Guerin <vincent.guerin@gemplus.com>
Ludovic Rousseau <ludovic.rousseau@gemplus.com>
2.2 1 février 2001
|
