Last commit for WorkletSecurity.tex: 0ac09e619666db9a9edf9c43e3b7c3868bd3c1fe

merged Security branch back to main branch. had to do WVM, WVM_RMI_Transporter, and WVM_RMI_Transporter by hand. No problems otherwise. was the only file with many changes with the WVMRSL stuff and Security.

dp2041 [2002-09-20 15:33:13]
merged Security branch back to main branch.  had to do WVM, WVM_RMI_Transporter, and WVM_RMI_Transporter by hand.  No problems otherwise. was the only file with many changes with the WVMRSL stuff and Security.
  1. % CVS version control block - do not edit manually
  2. % $RCSfile$
  3. % $Revision$
  4. % $Date$
  5. % $Source$
  7. % to compile this file into a pdf or ps use the following
  8. % 1) latex WorkletSecurity.tex
  9. % for ps: 2) dvips -K WorkletSecurity -o
  10. % for pdf: 2) ps2pdf WorkletSecurity.pdf
  12. \documentclass[10pt]{article}
  13. \usepackage{doublespace}
  14. % \usepackage{geometry}
  15. % \geometry{verbose,letterpaper,lmargin=45mm,rmargin=45mm}
  17. \title{Worklet Security}
  18. \author{Dan Phung (}
  19. \date{Draft of \today}
  21. % \textheight=9.3in
  22. % \topmargin=.2in
  23. \renewcommand{\baselinestretch}{1.5}
  25. \begin{document}
  27. % \begin{singlespace}
  28. % \end{singlespace}
  30. \section{Abstract}
  32. The goal of this project was to add security features to the Worklets
  33. system while leaving previous functionality intact where it was
  34. feasible. I found possible communication related security risks to be
  35. within the RMI transport layer, the WVM transporter layer and their
  36. associated class loaders. Intrusions are now minimized through the
  37. addition of SSL (Secure Socket Layer) sockets to the RMI Registry, RMI
  38. sockets, WVM Transporter and associated class loaders. and a
  39. HostnameVerifier. These security features require Java 1.4, which
  40. includes JSSE (Java Secure Sockets Extension) and JCE (Java
  41. Cryptography Extension). With all previous functionally retained,
  42. communication between WVMs can now be authenticated to ensure peer
  43. validity and encrypted to uphold packet integrity. These security
  44. parameters can also be tailored according to the security needs at
  45. each site.
  47. \section{Intro}
  49. The goal of the Worklet Security project was to analyze the Worklet
  50. system to determine the security hazards and to implement provisions
  51. for secure methods of communication that minimize those hazards. The
  52. Worklet system previously had no ability to authenticate the local or
  53. remote WVM hosts, nor were the packets encrypted. Without these
  54. features there is the possibility for the transmission and execution of
  55. malicious Worklets.
  57. % SYMMETRIC and ASYMMETRIC keys.
  58. \section{Background}
  60. As stated in the JSSE documentation: \begin{quote}``Integrity means
  61. that the data has not been modified or tampered with, and authenticity
  62. means the data indeed comes from whoever claims to have created and
  63. signed it.''\end{quote}
  65. Therefore, to secure the Worklet system we must validate the local and
  66. remote hosts and encrypt the Worklet code being sent. The Worklet
  67. security system is based off of public/private keys. One of the
  68. considerations in the implementation of a security architecture is
  69. whether to use symmetric and asymmetric keys.
  71. Symmetric algorithms involve the sharing of keys for encryption and
  72. decryption. A different set of keys must be kept for each pair of
  73. users. The weakness of these algorithms is that once the key is
  74. intercepted the security of the system is no longer viable. The
  75. advantage of these algorithms is that they do not consume too much
  76. computing power and are faster than asymmetric algorithms. Typical
  77. symmetric algorithm are DES (Data Encryption Standard), 3DES, and
  80. Asymmetric algorithms use pairs of public/private keys. The public key
  81. is used for encryption and the private key, or secret key, is used for
  82. decryption. Usually the public key is shared to anyone that wants to
  83. encrypt data, and only the receiver keeps the private key. Because
  84. the private key is kept secret the risk of the system is less than
  85. with symmetric keys. A typical set of keys for a single user is thus
  86. a private key to decrypt incoming data and a set of public keys that
  87. is used to send data to peers. Public keys are also usually digitally
  88. signed by third party certificate authorities (but they can be
  89. self-signed) to ensure their validity upon distribution. The strength
  90. of this algorithm is the higher reliability in key integrity. The
  91. disadvantages are that these algorithms are more complex to handle and
  92. usually take higher computing power and are thus much slower. Typical
  93. asymmetric algorithms are RSA (Rivest, Shamir, and Adelman) and DSA
  94. (Digital Signature Algorithm).
  96. The JSSE implementation used in the Worklet system is a combination of
  97. symmetric and asymmetric
  98. algorithms\footnote{\#HowSSLWorks}.
  99. It uses asymmetric key algorithms in the authentication phase of
  100. communication and symmetric keys to encrypt the data in the transport
  101. phase. The use of both algorithms allows the advantages of both
  102. algorithms can be used.
  104. % this section to be the distributed Worklet Security documentation.
  105. \section{Program Documentation}
  106. The Worklet security system provides methods for securing Worklet
  107. transmission. The vulnerable objects are the RMI (Remote Method
  108. Invocation) transport layer, the WVM (Worklet Virtual Machine)
  109. transport layer and the class loaders. Other objects that have or
  110. provide methods for security measures are HostnameVerifier and
  111. WorkletJunctions.
  113. The RMI Transport layer involves an RMI registry, associated RMI
  114. servers and class loaders. Only one registry can be created on a
  115. specific host:port to which many RMI servers can be bound. A secure
  116. registry authenticates all registry calls such as server lookups,
  117. binds, and unbinds. A secure RMI server uses custom secure sockets to
  118. authenticate and encrypt all communication. In the instance of a
  119. secure server, the default RMI class loader is set to our own
  120. implementation that uses a class loader with secure sockets. Both
  121. plain and secure RMI servers can be bound to plain registries but only
  122. secure RMI servers can be bound to secure registries. Communication
  123. between RMI servers can only proceed plain-plain or secure-secure.
  124. Depending on the security level (described in the Usage section) the
  125. RMI server could have either only plain, only secure, or both class
  126. loaders available to load classes.
  128. The WVM transport layer includes server sockets and class loaders.
  129. Depending on the level of security the transport layer can be created
  130. with plain, secure, or both types of server sockets and associated
  131. class loaders.
  133. A HostnameVerifier is also implemented and is used on the remote
  134. (receiving) end. This object is used by the remote host if the
  135. hostname of the sending WVM is not recognized from the CA certificate
  136. file. The specification of the hosts that are allowed and denied is
  137. described in the usage section.
  139. There are situations where the user of the WorkletJunctions could be
  140. uncertain of the security specifications at a certain WVM. The user
  141. can now specify parameters that allow the users to specify which
  142. methods of transport (plain RMI, secure RMI, plain socket, secure
  143. socket) the WorkletJunction should try and in what order. The RMI
  144. related methods specify what type of communication to try when looking
  145. up the recipient RMI server, not the actual RMI server. The socket
  146. related features specify the type of socket to try connecting on. The
  147. ability to specify transport methods contributes to the robustness of
  148. WorkletJunction communication.
  150. \subsection{Usage}
  152. Note that all previous functionality is retained. This section
  153. documents the features pertinent to Worklet Security. I make a
  154. delineation between the remote and local hosts. The remote
  155. host represents the intended recipient of the Worklet while the
  156. local host is the entity that is sending the Worklet.
  158. \subsubsection{Remote Host}
  159. To create a plain host you need not specify any parameters, like
  160. this:
  162. \begin{verbatim}
  163. java psl.worklets.WVM
  164. \end{verbatim}
  166. The name and port of the RMI server will default to WVM\_Host and
  167. 9100. If a remote host is created in this manner communication will
  168. not be authenticated nor encrypted. You can specify the RMI server
  169. name and port by using the switches -name and -port. See java
  170. psl.worklets.WVM -help for option details.
  172. To create secure hosts you must specify at least the keys file,
  173. password, and WVM properties file (WVM file). Because the WVM file
  174. must contain the keysfile and password it is usually sufficient to
  175. simply specify the WVM file. The keys file is the file containing the
  176. public/private keys of the host and the password is the passphrase
  177. specified in the creation of the keysfile. For more information on
  178. how to create a keysfile see the FAQ below. The WVM file holds the
  179. security specifications. These security specifications can be
  180. specified by setting environment variables with the -D java switch or
  181. on the command line. The parameter loading precedence is:
  182. \begin{enumerate}
  183. \item Environment variables
  184. \item WVM file
  185. \item command line specification
  186. \end{enumerate}
  188. The WVM file contains property=value pairs separated by white space.
  189. The important parameters in the WVM file are the keysfile and
  190. password as these are used by the Worklet system at different times.
  191. There is also an internally needed parameter that needs to be set in
  192. the WVM file, namely:
  193. \begin{verbatim}
  194. java.rmi.server.RMIClassLoaderSpi=psl.worklets.WVM_RMIClassLoaderSpi
  195. \end{verbatim}
  197. It is \textbf{very} important that the security of this file is set at
  198. the operating systems level, meaning that the permissions on this file
  199. should be set accordingly. For example, for maximum security I would
  200. set the permission to user read-only. This can be done under Unix
  201. with the following:
  203. \begin{verbatim}
  204. chmod a-rwx wvm_properties
  205. chmod u+r wvm_properties
  206. \end{verbatim}
  208. Included with the distribution should be an example WVM file named
  209. ``wvm\_properties''. It should look like this:
  211. \begin{verbatim}
  212. # this first line is needed for internal purposes.
  213. java.rmi.server.RMIClassLoaderSpi=psl.worklets.WVM_RMIClassLoaderSpi
  215. # WVM host related parameters
  216. WVM_RMI_PORT=9100 # port that the rmi registry will be created on
  217. WVM_RMI_NAME=target # name that the RMI server will be bound to
  219. # Security related parameters
  220. WVM_KEYSFILE=testkeys # file holding the public/private keys
  221. WVM_PASSWORD=passphrase # password into the keysfile.
  222. WVM_SSLCONTEXT=TLS # SSL context instance to use
  223. WVM_KEYMANAGER=SunX509 # key manager implementation type
  224. WVM_KEYSTORE=JKS # key store implementation type
  225. WVM_RNG=SHA1PRNG # random number generator algorithm to use
  226. # location of the certified security certificates.
  227. WVM_HOSTS_ALLOW=localhost, # allowed hosts
  228. WVM_HOSTS_DENY= # denied hosts
  229. WVM_FILE=wvm_properties # reference to this file
  231. # security level of the WVM.
  232. # 0: no security.
  233. # 1: low security = plain RMI Registry, secure RMI server,
  234. # plain and secure server sockets, and
  235. # plain and secure class loaders.
  236. # 2: medium security = same as 1 but with a secure RMI Registry
  237. # 3: high security = secure RMI Registry, secure RMI server,
  238. # secure server socket and secure class loaders.
  240. \end{verbatim}
  242. Notice the last parameter of WVM\_SECURITY\_LEVEL. This parameter is
  243. what you would modify to tailor the security level according to the
  244. needs at a certain WVM. A security level of 1 is the most flexible as
  245. it creates a registry that will allow binding by both plain and secure
  246. RMI servers. Also created with a security level of 1 are plain and
  247. secure server sockets and class loaders. The only difference between
  248. security level 1 and 2 is that the registry is secure in the latter.
  249. A security level of 3 creates a WVM host that has a secure RMI server
  250. that must be bound to a secure registry, a secure server socket, and only
  251. secure class loaders. There is a plain server socket created, but
  252. that is used only for internal purposes for robust registry upkeep.
  254. The WVM\_HOSTS\_ALLOW and WVM\_HOSTS\_DENY specify which hosts on the
  255. remote end are allowed and denied. If no hosts are specified in both
  256. settings, then all hosts will be allowed. These entries are the only
  257. parameters that are concatenated, meaning that if you specify these
  258. parameters in the system environment, the WVM file, and on the command
  259. line then all entries will be used.
  261. \subsubsection{Examples}
  264. \begin{verbatim}
  265. java psl.worklets.WVM -name target
  266. \end{verbatim}
  267. Create a plain host with the RMI name target on port 9100.
  269. \begin{verbatim}
  270. java psl.worklets.WVM -wvmfile wvm_properties
  271. \end{verbatim}
  272. Create a host according to the parameters in the WVM file.
  274. \begin{verbatim}
  275. java -DWVM_FILE=wvm_properties psl.worklets.WVM -name target -S 2
  276. \end{verbatim}
  277. Create a host according to the parameters in the WVM file, but with
  278. the RMI name target and a security level of 2.
  280. \subsubsection{Local Host}
  282. The sending of secure Worklets involves the creation of a local WVM
  283. host that bootstraps the Worklet into the WVM system. Creation of
  284. secure Worklets and WorkletJunctions is the same as described in the
  285. Worklet documentation except that you need to set the WVM\_FILE system
  286. property to your WVM file (described above). This can either be done
  287. with the -D java switch or within the application with the
  288. System.setProperty method. Included in the distribution should be an
  289. example program ``''.
  291. Here is the portion within the example program that sets the security
  292. parameters. Also shown is the creation of the WVM.
  294. \begin{verbatim}
  295. psl.worklets.OptionsParser op = new psl.worklets.OptionsParser();
  296. op.loadWVMFile(System.getProperty("WVM_FILE"));
  297. op.setWVMProperties();
  299. wvm = new psl.worklets.WVM(new Object(), InetAddress.getLocalHost().getHostAddress(),
  300. "SendSecure", op.port, op.keysfile, op.password,
  301. op.ctx, op.kmf, op.ks, op.rng, op.securityLevel);
  302. \end{verbatim}
  304. The WVM\_FILE system property was set on the command line like this: \\
  305. \begin{verbatim}
  306. java -DWVM_FILE=wvm_properties SendSecure localhost target 9101 Apps.Face 1 0 mysend
  307. \end{verbatim}
  309. You can also manage the WorkletJunction transport methods by setting
  310. the transportMethods to a combination of plainRMI, secureRMI,
  311. plainSocket, and secureSocket. The plainRMI and secureRMI keywords
  312. specify the type of registry used by that server. The type of server
  313. cannot be specified because the parameters for which type of socket to
  314. use is set at creation time. The plainSocket and secureSocket
  315. keywords specify which type of socket to communicate with. The
  316. security will always default to the ``parent'' if not set. So if the
  317. Worklet.isSecure and the WorkletJunction.isSecure have not been
  318. specified, then the WorkletJunction will default to the security of
  319. the current WVM system. The default for plain systems is plainRMI and
  320. plainSocket and the default for secure systems is secureRMI and
  321. secureSocket. If WorkletJunction.isSecure is set and the
  322. WorkletJunction.isSecure has not been set then those WorkletJunctions
  323. will default to the security level of the Worklet. The last, and
  324. highest priority level is at the WorkletJunction. You can either use
  325. the isSecure method or specify the methods through the
  326. transportMethods function. Using the transportMethods function alone
  327. is sufficient, and will override the isSecure method. Here's an
  328. example of how to set the methods:
  330. \begin{verbatim}
  331. String[] tm = {"secureRMI", "plainRMI", "secureSocket", "plainSocket"};
  332. wjxn.setTransportMethods(tm);
  333. \end{verbatim}
  335. \section{Program Documentation - Internal}
  336. % need to talk about registry blah through sockets.
  337. This section describes added and modified features in the Worklet
  338. system. These features include an SSL socket factory, robust RMI
  339. registry handling, an implementation of RMIClassLoaderSpi and
  340. HostnameVerifier, and an OptionsParser.
  342. The SSL socket factory, WVM\_SSLSocketFactory, implemented in
  343. the Worklet system was derived from the JSSE sample included in the
  344. J2SDK 1.4 distribution. I packaged the functionality of the JSSE
  345. sample code together in one class and gave the user access to modify
  346. the security parameters. I also have WVM\_SSLSocketFactory
  347. extending RMISocketFactory and implementing RMIServerSocketFactory,
  348. RMIClientSocketFactory, and Serializable so that this factory can also
  349. be used as our custom RMI socket factory. The available methods are:
  350. createSocket(), createServerSocket(), getSSLSocketFactory(), and
  351. getSSLServerSocketFactory(). The reason why I have a private
  352. initFactories() method is because when the object serialized, all the
  353. members are instantiated as null, so they must be reinstantiated on the
  354. remote side.
  356. For robust registry maintenance I modified the
  357. WVM\_RMI\_Transporter.shutdown() method and added a
  358. WVM\_Registry and RTU\_Registrar. During WVM
  359. instantiation a plain socket will always be created. This socket will
  360. be used by the RMI registry and server to broadcast registry creation
  361. and rebinding requests during shutdown, along with the normal WVM
  362. operations. If the security level is 3, or high security, then the
  363. plain socket will only accept RMI registry and server related
  364. requests. This implementation allows plain and secure RMI servers to
  365. bind onto a registry and communicate events related to the registry.
  366. The hostname, socket port number, and RMI name along with a randomly
  367. created key comprise the registration information needed by our
  368. registry to keep track of the bound servers. I subclassed the default
  369. RMI Registry in WVM\_Registry to add the features of
  370. maintaining bound servers and restricting the rebinding method. The
  371. RTU\_RegistrarImpl, an implementation of the
  372. RTU\_Registrar, acts as an intermediate between the registry
  373. and the RTU (our RMI server.) It creates and manages the registration
  374. information for each server and negotiates the binding of the server
  375. to our registry.
  377. % need to talk about hostname verifier
  378. A WVM\_HostnameVerifier was also added to the Worklets system as a
  379. security extension. This class was needed internally to verify hosts
  380. not included in the CA certs file. This object uses the
  381. WVM\_HOSTS\_ALLOW and WVM\_HOSTS\_DENY system properties. See the
  382. ``Program Documentation '' section for details on how to
  383. set these.
  385. % WVM_RMIClassLoaderSpi
  386. The WVM\_RMIClassLoaderSpi allows us to specify the use of our own
  387. class loader. The default RMI class loader and system class loader
  388. does not use secure sockets, nor are there ways to specify the use of
  389. our sockets or socket factories. The WVM\_RMIClassLoaderSpi specifies
  390. our WVM\_ClassLoader which can be instructed to use secure sockets.
  391. The specification to the system to use our RMI class loader is done by
  392. setting the system environment variable as such:
  393. \begin{verbatim}
  394. java.rmi.server.RMIClassLoaderSpi=psl.worklets.WVM_RMIClassLoaderSpi.
  395. \end{verbatim}
  396. This parameter is usually put in the WVM file. To ease the load of
  397. our class loader and to maintain the speed of the Worklets system, the
  398. WVM\_RMIClassLoaderSpi does not load the following classes: java.*,
  399. javax.*, sun.*, sunw.*, and psl.*
  401. I added an OptionsParser to ease the handling of the multitude
  402. of added parameters that can be specified. The OptionsParser
  403. parses the command line as well as related environment variables and
  404. the WVM file. An OptionsParser has public access and can be
  405. used to load in the security parameters in user programs. For example
  406. of this procedure see the ``Local side'' section in the ``Program
  407. Documentation''.
  409. \subsection{Possible errors}
  410. \begin{itemize}
  412. \item The most common errors pertain to the keysfile and the file
  413. holding the CA certificates. Either these files are spelled
  414. incorrectly when specified or the password is incorrect. Another
  415. thing to check is that the permissions for the files at least give
  416. user read rights.
  418. \item RMI server cannot bind to registry.
  420. Upon trying to bind a RMI server, if you get this error:
  421. \begin{verbatim}
  422. Shutting down; cannot bind to a non-local host: RemoteException occurred in server thread; nested exception is:
  423. java.rmi.UnmarshalException: Transport return code invalid
  424. \end{verbatim}
  426. Check that the security level of the server and registry are
  427. compliant. If it is secure, then it is expecting the registry to be
  428. secure as well, and is thus communicating through secure protocols.
  429. Security levels of 0 and 1 (none, and low) can bind on the same
  430. registry. Security levels of 2 and 3 (medium and high) can also bind
  431. together on the same registry, but cannot be matched with levels 0 and
  432. 1. Another issue to be aware of is the RMI class loader of the
  433. Registry. If the Registry is created with a secure RMI server, the
  434. instatiation of the server sets the RMI class loader to our secure
  435. implementation and essentially sets the RMI class loader for that JVM.
  436. Therefore when other non-secure servers try to bind, the registry
  437. interacts with the secure RMI class loader, and a remote exception is
  438. thrown. To prevent this from happening you should create the registry
  439. with a plain server.
  441. \end{itemize}
  443. \subsection{Frequently Asked Questions (FAQ)}
  444. \begin{itemize}
  446. \item How do I create my own public/private keystore and how
  447. do I self certify it?
  449. Here is an example of how to create a keystore named testkeys with the
  450. password asd123. In general you do not want to specify the password
  451. in the command used. When not specified on the command line the
  452. keytool program will prompt you for a password. The following
  453. command line should all be on the same line.
  455. keytool -genkey -dname "cn=Foo Bar, ou=Columbia University, o=PSL, \
  456. c=US" -alias foobar -keypass asd123 -keystore testkeys \
  457. -storepass asd123 -validity 180
  459. The example also self-certifies the keystore with a validity time of
  460. 180 days. A better way to certify the keystore would be to create a
  461. certificate request and then send it to a third party certifier (see
  462. Java JSSE docs). The entries that reside in the WVM file that are
  463. related to the file that was just created are:
  464. \begin{verbatim}
  465. WVM_KEYSFILE=testkeys
  466. WVM_PASSWORD=asd123
  468. \end{verbatim}
  470. to view details about the keystore you can do:
  471. \begin{verbatim}
  472. keytool -list -keystore testkeys
  473. \end{verbatim}
  475. For for information see: \\
  478. \item Where do I find out more information about the available
  479. algorithms that I can use?
  481. See the Java documentation about security. Specifically, look at the
  482. JSSE and JCE docs.
  484. \item What about java policies?
  486. In my implementation the java policies do not play a role.
  488. \end{itemize}
  490. % DONE
  491. \section{Conclusion}
  493. The security features implemented for the Worklet Security project
  494. provides the methods for secure Worklet communication. Security
  495. measurements can only at best minimize the risks inherent in network
  496. communication and is only as effective as the awareness of the user.
  498. \section{Future Enhancements}
  499. \begin{itemize}
  500. \item have a better way to pass in the password to the WVM\_RMIClassLoaderSpi.
  501. \end{itemize}
  503. \end{document}
  505. DEMO
  506. overview the Worklets system. show that the holes are at:
  507. RMI: registry-RMI server, RMI server-RMI server, RMI Class Loader
  508. sockets: socket-socket, ClassLoader.
  510. First we should talk about the different transports used in the
  511. Worklet system.
  513. RMI:
  514. - true -,
  515. - true +/no class loading
  516. - true +/with class loading
  518. sockets:
  519. - true -,
  520. - true +/no class loading
  521. - true +/with class loading
  523. Registry
  524. - creation of plain registry > bind to registry
  525. - creation of secure registry > bind to plain and secure registry
  526. - RMI send to plain
  527. - RMI send to secure
  529. power point presentation
  530. before security
  531. - danger to WVM
  532. - danger to worklet
  533. - no RMI authentication
  534. - no socket authetication
  535. - anyone can see the code being sent between sockets
  537. demo:
  539. 1) <RMI REGISTRIES>
  541. we should show that plain communication still works bring up a plain
  542. external registry bind both a secure and plain server to those.
  543. explain that these are both communicating with plain communication
  544. through Naming.
  546. create a secure external registry. show how only secure
  547. WVM's can bind to it.
  549. explain the plain server contacting secure server problem, and
  550. how if security is downgraded, it will be lost in that registry
  551. system.
  553. it was possible to kill a RMI host, binded to a certain name, then to
  554. bind another host to that name. now the servers are authenticated
  555. through the registry before binding can occur (or even a lookup).
  556. also, only psl.worklets.WVM_RMI_Transporters can rebind.
  558. <WVM>
  560. security levels. level 1 is everything is secure except for the
  561. registry. the registry is still plain to allow binding with other
  562. non-secure RMI servers, also, plain sockets are still up. level 2 is
  563. all secure, with the secure registry. also, plain sockets are still
  564. up. level 3 is secure only. only secure rmi and sockets are available,
  565. along with only secure codebases.
  568. if security is set, then we have a https class server, but we
  569. also still the normal http server. only if the security
  570. level is at 3, secure only, is only the https server up.
  572. <WVMFILE>
  573. explain all the fields
  574. show java psl.worklets.WVM --help
  575. explain the scaffolding of the parameters, environment, wvmfile,
  576. command line.
  578. <RMIClassLoaderSpi>
  579. --needs the wvmfile. security on the file must be at the OS level,
  580. setting of file permissions. ask for other suggestions on how do this.
  583. the HostnameVerifier is for the remote host to allow class loading.
  586. ability to set the transport methods.
  588. so there are ways to go between secure and plain WVM's
  590. RMI -/-> sRMI
  592. host-remote
  593. WVM-WVM: only plain transports are available.
  594. WVM-sWVM: cannot send through RMI
  595. depends: securityLevel 1,2: can send through plain socket.
  596. if securityLevel 3, then cannot send through sockets.
  598. sWVM WVM:
  600. sWVM sWVM: depends
  601. RMI,
  603. so security is not at the workletJunction level. it is between hosts.
  607. So we are going to use symmteric keys. The creation and management of
  608. these keys and certificates are discussed in detail with the JSSE
  609. documentation that is a part of Java SDK 1.4. The tool used to create
  610. and manage the keystore is ``keytool.'' Here I will briefly go
  611. through an example of key and certificate creation. The keystore and
  612. its password are the required parameters for Worklet Security that
  613. need to reside in the WVM file.
  615. Here is an example of how to create a keystore named testkeys
  616. with the password asd123. In general you do not want to specify
  617. the password in the command used. Rather, when not specified
  618. on the command line the keytool program will prompt you for a
  619. password.
  621. keytool -genkey -dname "cn=Foo Bar, ou=PSL, o=PSL, c=US" \
  622. -alias foobar -keypass asd123 -keystore testkeys \
  623. -storepass asd123 -validity 180
  625. The example also self-certifies the keystore with a validity time of
  626. 180 days. A better way to certify the keystore would be to create a
  627. certificate request and then send it to a third party certifier (see
  628. java jssse docs). The entries that reside in the WVM file are that
  629. are related to the file that was just created are:
  630. WVM_KEYSFILE=testkeys
  631. WVM_PASSWORD=asd123
  634. to view details about the keystore you can do:
  635. keytool -list -keystore testkeys
  639. - The (WVM) has its own method of contacting peers to broadcast the RMI
  640. registry shutdown.