java security2nd 读后 概要整理

第三部分 Java Security 2nd

第二章  The default Sandbox

Java permission:

Keystore: 为什么要在Java Permission 里面讲呢？

Policy Files: p38

   In order to administer the Java sandbox, you list the various permissions we've discussed in a Java policy file.Java virtual machines can use any number of policy files, but there are two that are used by default. There is a global policy file named $JREHOME/lib/security/java.policy that is used by all instances of a virtual machine on a host. We consider this to be a global policy file because it allows an environment where the JRE is mounted from a common server by several machines; each of these machines will share the definitions in this file.

   In addition, there is a user−specific policy file called .java.policy that may exist in each user's home directory ($HOME on UNIX systems, C:\WINDOWS on single−user Windows 98 systems, and so on). The set of permissions given to a program is the union of permissions contained in the global and user−specific policy files.

 

Here's how a typical policy file might look:

keystore "${user.home}${/}.keystore";

// Grant these permissions to code loaded from O'Reilly, regardless of

// whether the code is signed.

grant codeBase "http://www.oreilly.com/" {

permission java.io.FilePermission "/tmp", "read";

permission java.lang.RuntimePermission "queuePrintJob";

};

// Grant these permissions to code loaded from Sun but only if it is

// signed by sdo.

grant signedBy "sdo", codeBase "http://www.sun.com/" {

permission java.security.AllPermission;

};

// Grant these permissions to code signed by jra, no matter where it

// was loaded from

grant signedBy "jra" {

permission java.net.SocketPermission "*:1024−",

"accept, connect, listen, resolve";

};

// Grant these permissions to any code, no matter where it came

// from or whether it is signed

grant {

permission java.util.PropertyPermission

"java.version", "read";

};

Note how the policy file combines all the elements of the sandbox: the code sources (the combination of signedBy and codeBase elements) are associated with various permissions to create protection domains;the entire file is subject to the given keystore.

   The first line of this example tells the virtual machine to consult the keystore in the file $HOME/.keystore when it needs to check the certificates of entities that have signed code. The next four blocks of text define protection domains: code that is loaded from O'Reilly's web site has permission to read files in /tmp and to start a print job; code that is signed by sdo and loaded from Sun's web site has permission to do anything it wants to; code that is signed by jra is able to operate on any nonprivileged socket; and all code is allowed to read the java.vendor system property. In each of these blocks, the syntax is the same: the word grant is followed by a code source and then a set of permissions enclosed by braces. The code source is composed of acodebase and a signer, either of which may be blank.

 

第三章 java语言的安全

1.Java 语言安全结构

a) Private

b) Protected

c) public

d) Finall的相关规则

e) 对象序列化和内存完整性

2.java 语言规则的实施

a) 编译实施

b) 字节码校验器（组成，内部组成，推迟的字节码校验）

c) 运行时的规则

3.与之前版本的比较

 

第四章：SecurityManager

l The security manager, which provides the mechanism that the Java API uses to see if security−related operations are allowed.

l The access controller, which provides the basis of the default implementation of the security manager.

l The class loader, which encapsulates information about security policies and classes.

    The purpose of the security manager is to determine whether particular operations should be permitted or denied. In truth, the purpose of the access controller is really the same: it decides whether access to a critical system resource should be permitted or denied. Hence, the access controller can do everything the security manager can do.

 

    沙盒模型，由SecurityManager 类编码，以软件的形式实现了一种特定的安全策略，而这

种软件以实施特定的安全策略为主要目的，这意味着要实施不同的安全策略，必须使用一种

特定版本的软件.

    最初的设计使得J D K执行的安全核查难以编写相应的代码。例如，当检查一个文件是否

可读打开时，需要调用S e c u r i t y M a n a g e r类中的c h e c k R e a d ( )方法。显然，这样的设计方法不适合今后的J D K的新型核查处理，所以它不易扩展。并且，也不易改变规模。例如，为产生一种新型访问核查，如某人去检查钱是否从银行帐户中提出一类的事情，必须要在

S e c u r i t y M a n a g e r类或它的子类中增加c h e c k A c c o u t Wi t h d r a w ( )方法。

。J D K 1 . 2结构引入了可定义类型的访问控制许可权和一种自动处理机制来实现可扩展性和规模可改变性。在理论上， S e c u r i t y M a n a g e r类中不需要再加入新的方法。在J D K 1 . 2的发展过程中，当我们引入大量新型安全核查时，并不需要新的方法，一个名叫c h e c k P e r m i s s i o n ( )的方法，已经足以处理所有的安全核查。安全核查应该扩展到所有的J a v a程序，包括a p p l e t和应用程序。在最初的J D K 1 . 0和随后的J D K 1 . 1中，一些内部安全机制在设计和实现时所用的技术是相当脆弱的。尽管它们在这些版本中运行得很好，但维护和扩展它们相当困难。因此，为了降低在程序中产生这些小安全漏洞的危险性，我们作了一些重要的结构性调整。这些工作涉及到对S e c u r i t y M a n a g e r和C l a s s L o a d e r类的设计和实现上的修正，和基本访问控制核查机制的修正。下面的3 . 8和3 . 9节会谈到一些历史上的细节。

在运行Java 程序的时候默认的设置是不安装安全管理器的，这样所有的操作都是允许的，另一方面，applet浏览器会执行一个功能受限的安全策略。

 

     举例说明java securityManager 在一个默认的本地类中是怎么运行的，比如创建一个fileReader ,

 FileReader-->FileInputStream-->SecurityManager.checkRead()-->CheckPermission(new file permission())-->java.security.AccessController.checkPermission(perm);--->在这个方法里面实现检查 code base ，stack,domain,permission

 

在securityMemmanger 里面这个 保护域的理解。。。？？

Security 2nd 里面 p60有一下内容：对蓝色内容表示不理解

If you carefully considered the list of methods in the table above, you were probably surprised not to see an obvious method to check: the actual read( ) or write( ) methods of any of the File classes. The assumption here is that a trusted class is responsible for determining the security policy associated with any particular File object; if the trusted class decides that it is okay for an untrusted class to perform I/O on a particular File*Stream object, then it is free to deliver that object to the untrusted class, and the untrusted class is free to read or write to that object. This implementation also allows for much greater efficiency: if the

program had to check with the security manager every time it called the read( ) or write( ) methods,I/O performance would drastically suffer.

 

 public FileInputStream(File file) throws FileNotFoundException {

        String name = (file != null ? file.getPath() : null);

        SecurityManager security = System.getSecurityManager();

        if (security != null) {

            security.checkRead(name);

        }

 

 

第五章：存取控制器  AccessControl

a) 概念: Code source ,permission ,policy

b) 安装policy 给class ： -Djava.security.policy=awtWindowPolicy.jp

c) 安装policy 给jdk 修改java.security 文件, plicy.provider=sun.security.provider.PolicyFile

第六章：Java 类装载器 ClassLoader

a) 类装载器，java ClassLoader 提供了一种机制，可以把包含java字节码的文件，读入到JAVA虚拟机中，并转换成类的形式

b) 提供三方面的操作：

i. 结合虚拟机定义名称空间，保护语言本身安全特性的完整性。

ii. 必要时候调用安全管理器，保证代码在定义或访问类时有适当的权限

iii. 建立权限和类对象之间的映射。

c) 类装载器任务

i. 询问安全管理器是否允许程序访问当前处理的类

ii. 如果已经载入，寻找以前的类对象

iii. 若没载入，询问其父类装载器是否知道如何载入。

iv. 询问安全管理器是否允许程序创建当前处理的类

v. 向一个字节数组读入类文件

vi. 为该类创建保护域。

vii. 在findClass 中，调用defineClass 方法，由字节码构造一个class对象。

viii. 进一步解析处理，引用的类应该由当前类装载器找到。

d) 其他类装载器

i. RMIClassLoader()

第七章:加密介绍

a) 鉴别的需要：从网上下载的类如何实现鉴别

i. 身份鉴别（作者鉴别） ： 确定是想要的那个发送者发送的数据

ii. 修改鉴别（数据鉴别）： 确定接收到的内容没有经过修改

b) 作者鉴别：黑客常常使用DNS ISP 伪装让使用者误以为是真实的发送方发送过来的数据。

c) 数据鉴别：黑客会在数据从一个site 到另外一个site的时候进行数据修改

d) 加密引擎：在JAVA安全软件包中包含两个加密引擎，消息摘要(mess digest engine) 和数字签名引擎(digital signature engine)

e) 加密密钥

i. 密钥：对称加密用的密钥(secret key),当算法需要一个密钥时，加密和解密双方都需要使用同一密钥，双方必须协商保护好密钥。

ii. 密钥对：公钥(public key)和私钥(private key)。采用公钥加密，私钥解密的方式。

f) 消息摘要

i. 即数字指纹。将一个简单的数据流作为输入，产生一个简单的输出。输出的内容即为消息摘要。

ii. 意义：一组特定数据的摘要并不能反映此数据的任何信息，无法从一个消息摘要中知道数据有多少和内容是什么。如果想确定一个摘要是否代表了某数据，需要重新计算一次摘要，并与原摘要内容作比较。如果两个摘要相同则证明摘要的合法性。一位改变或者丢失消息摘要变不同。

iii. 要求：好的消息摘要算法必须保证两个不同的消息在同一算法上计算消息摘要，不可能得到同一个结果。

iv. 用法：摘要通常会与它所表示的数据同时发送给数据的接受者，接受者重新计算摘要，保证原数据没有被改变。

g) 数字签名：

i. 数字签名可以证明某个实体的身份。

ii. 条件：数字签名的使用者首先要具备产生消息摘要的能力，其次是为此摘要进行加密的能力。

iii. 使用过程：

1. 发送方：原数据计算摘要，使用发送者私钥对摘要加密，形成数字签名。发送

2. 接收方：用发送方公钥解开数字签名，获得消息摘要；对原数据计算摘要；把新计算获得的摘要与解开的摘要进行比对验证数据是否被改变。

问题：

1.接收方使用原数据进行验证，如何获得原数据？

2.如何保证原数据密文状态的传递。

h) Java 中的加密引擎

i. JCE

ii. JSSE

第八章：安全提供者 Security Provider

a) 体系结构中各个组件

i. Engine Class：Java虚拟机中提供的核心API

ii. Algorihm class ： 针对每一种引擎都有一种实现的算法

iii. The Provider Class: 管理各个provider的类。

iv. Security Class：维护一个provider class的列表，并且查看每个provider可提供的操作。

b) Provider 的选择：

i. 采用哪个Provider 在$JREHOME/lib/security/java.security 中设置

security.provider.1=sun.security.provider.Sun

security.provider.2=com.sun.rsajca.Provider

两个提供者类，第一个是sun.security.provider.Sun，第二个是com.sun.rsajca.Provider，当请求security类提供的一个特定的引擎和算法时，他会按顺序查找每个提供者，知道找到第一个可以提供所需操作的类。

第九章： 密钥与证书

a) 密钥：公开密钥，私有密钥，对称密钥

b) 证书：主要用于公开密钥的鉴别，通常将公开密钥放在证书中实现传输。

c) 非对称密钥：SunProvider: DSA 和 RSA，JCEProvider:Differ-Hellman

d) 对称密钥：JCE：Blowfish,DES,DESede,HmacMD5,HmacSHA1PBEWithMD5AndDES, and PBEWithMD5AndTripleDES

e) 密钥生成：KeyPairGenerator,

f) 密钥工厂：主要用于导入和输出密钥。为了方便传输，密钥需要采用一种外部格式，到达目标后再将它还原成内部表示，而工厂可以将密钥从一种格式翻译或者转换成另一种格式。传输时采用两种形式：一种是编码格式，另一种是利用生成密钥的参数。都可以采用java.security.KeyFactory和javax.crypto.SecretKeyFactory进行交互。

g) 证书：针对数字签名中无法得到原数据进行验证对方身份的问题，通过一个公正的实体即证书授权机构或CA来验证发给你的公开密钥的合法性。证书可以保证其中的公开密钥确实来自它的“发源地”。证书只能验证他所包含的公开密钥。

证书包含三方面的内容:

实体名，与主体相关的公钥，验证证书信息的数字签名。

由于证书带有CA的数字签名，我们就能验证此数字签名，如果验证成功，就可以相信其中的公开密钥确实属于证书所声称的实体。

Certificate 类，X509Certificate类， 撤销证书

密钥、证书与对象序列化

第十章：密钥管理

a) 概要：从数据签名到数据加密，都需要提供相应的密钥和证书，有时需要私有密钥，有时需要秘密密钥，有时候则需要秘密密钥，有时候则需要公开密钥。密钥管理系统就是要保存这些密钥，并且使你能够程序化的对他们进行访问。Java的密钥管理系统是采用基于密钥库的概念建立的。密钥库可以通过一个叫Keytool的工具来创建和维护，java也提供了相关的API,从而可以程序化的应用密钥库。

b) 密钥管理相关术语：

i. 密钥库（Keystore）：密钥库是一个文件，用于保存一组密钥和证书。此文件成为.keystore,其位置在用户的主目录Unix系统为$HOME,Windows系统为C:\windows,等。

ii. 别名(Alias)：密钥库中每个密钥都属于某个实体，对于实体可以设置别名。

iii. 标示名(Distinguished name,DN)：这是一个完整的X.500名的子集，这是一个很长的串。例如DN:

CN=Scott Oaks, OU=JSD, O=Sun Microsystems, L=NY, S=NY, C=US

iv. 密钥项：第一类：密钥项要么保存一个非对称密钥对，要么保存一个秘密密钥。如果保存的是一个密钥对，他还可能保存证书链。

v. 证书项：只包含一个公开密钥证书。保存的是一个单独的证书不是证书链。

vi. JKS JCEKS 和PKCS12：java 提供了三种不同的密钥库算法。

1. 默认算法JKS，完成密钥项和证书的读取和保存。这里只能保存私有密钥，如果想使用密钥库处理秘密密钥，就必须使用JCEKS实现。

2. JKS或JCEKS处理的私有密钥是经过加密的，JKS的加密强度要比JCEKS弱。这样是受美国出口限制。如果想调整密钥算法，需要编辑$JREHOME/lib/security/java.security文件，找到keystore.type一项将他设置成keystore.type=JCEKS

vii. 可信的证书授权机构：这些证书存放在$JREHOME/lib/security/cacerts中，他本身就是一个密钥库，里面的每一项都是CA的根证书。Thawte和Verisign 属于同一家公司，由于历史原因，两者的验证可信度有所区别，可以免费提交少量信息从Thawte获得个根证书，但是Verisign 就需要提供大量的信息而且还要付费。

c) Keytool 密钥工具：解释了Keytool的各种参数。

d) 密钥管理API: KeyStore 

e) 密钥管理实例：讲述了一个企业内部所有员工访问网络上一个jar 文件的例子

f) 秘密密钥管理：

i. 传统方法，非电子方式，邮寄一张存有密钥的软盘

ii. 利用公钥加密秘密密钥，实现传输，但是公开密钥加密的方法要比对称加密的方法慢得多。

iii. 密钥协议算法，在通信双方交换一些公开信息，利用这些信息计算一个共享的秘密密钥。

第十一章：消息摘要

a) 消息摘要类:MessageDigest

b) 安全的消息摘要：假设有人同时修改了文件中的文本和相应的摘要，而新摘要恰好表示了修改后的文本，那我们就没有办法了，因此采用MAC（Message Authentication Code,消息鉴别码），即仅有输入数据不能得到消息摘要，还需要一个有发送方和接收方共享的秘密密钥才能生成最后的MAC。若有人修改了数据和MAC那么接收方可能会发现有人修改了数据。

c) 只要在传输类和接受类中使用同一口令短语中的数据，消息摘要的比较结果就是相同的，这样就可以在一定程度上保障消息摘要的安全性，但仍需要发送方和接收方商量好选取什么数据作为口令短语，而且口令短语不能随文件一起发送。在这种情况下，消息摘要的安全性取决于口令短语的安全性。最好通过提示录入口令短语。

d) 消息摘要流：消息摘要流要求输入数据的形式为单独的字节序列或字节数组。更简单的方法是由文件或其他输入流读入数据。如DigestOutputStream,DigestInputStream

第十二章：数字签名

a) Signature类：创建签名，有一组数据创建其消息摘要，在利用私有密钥对消息摘要进行签名即可实现数字签名的创建。

b) 签名类：Java中数字签名最主要的应用是创建和验证签名类。

c) Jarsigner工具：它使用密钥库中的信息来查找某个特定实体的信息，并用词信息来对jar文件进行签名，或完成jar文件签名的验证。

i. SIGNER.SF 包含了与每一个类文件一一对应的SHA消息摘要。此摘要是根据类文件中的3行声明信息计算得到的。

ii. SIGNER.DSA 该文件中包括了.SF文件的数字签名，即实际的签名数据，格式为PKCS7。文件要与.SF的文件名匹配，扩展名为生成签名的算法。如果密钥时一个X509(DSA)密钥，就生成一个DSA签名，如果是一个RSA密钥，就生成一个RSA签名。

iii. 这些项，都保存在META-INF目录下。

d) 列举了了Jar文件的创建，和jarsigner的使用参数和方法。

第十三章：基于密码的加密

a) 密码引擎，在JCE中实现加密引擎，称为Cipher类，SunJCE提供的加密算法包括：

i. DES，数据加密标准

ii. DESede，三重DES或多重DES，进行三轮的DES加密或者解密操作。

iii. PBEWithMD5AndDES

iv. Blowfish

b) SunJCE指定的模式：

i. ECB：电子密文模式

ii. CBC：密码分组链接模式

iii. CFB：密文反馈模式

iv. OFB：输出反馈模式

v. PCBC：传播密码分组链接模式

c) SunJCE 提供的填补机制

i. PKCS5Pading

ii. Nopadding

d) Cipher 类的实现

e) 密码流：将加密对象与一个输入流或输出流联系起来，当把数据写到这样的输出流中时，会自动对数据进行加密，当输入流读取数据时，数据就自动解密。比如:CipherOutputStream，CipherInputSteam类。

第十四章：SSL与HTTPS

a) 通过JSSE实现SSL加密。SSL提供了在TCP上对数据进行加密的方法，这也是HTTPS协议的基础。

b) 使用SSL的特点：

i. 通用性。许多服务器都是以SSL为基础建立。

ii. 为秘密密钥提供一个简单的接口。SSL实现了两个操作，秘密密钥交换以及利用交换密钥进行数据加密。

iii. 所适用的环境中通常只有较少的服务器，而存在大量的客户机。

c) SSL握手过程

i. 客户启动到服务器的链接，并通知服务器客户所支持的SSL密码

ii. 服务器对此作出相应，并返回服务器所支持的SSL密码

iii. 服务器想客户发送一个证书以验证身份。

iv. 服务器启动一个密钥交换算法，发送证书中的部分信息来设置，并且将必要的密钥交换信息发送给客户。

v. 客户完成此密钥交换算法，将必要的密钥交换信息发送给服务器。到此为止服务器的证书就得到了验证。

vi. 基于密钥交换算法的类型，客户选择合适的密码，并通知服务器他要使用的哪种密码。

vii. 服务器最后决定使用的密码。

d) 密钥库keystore和信任库 tuststore

i. Keystore 与 tuststore 完全相同，都是通过keytool来管理，在程序设计方面没有什么区别，只是各自的功能有所不同。

ii. 密钥库可以用来同信任状，信任库用来验证信任状。

e) JSSE证书：

i. JSSE定义了另一个证书类，javax.security.cert.Certificate  此类与之前的java.security.cert.Certificate没有关系。只是sun JSSE 提供了javax.security.cert.Certificate这个类

f) SSL客户与服务器套接字

i. SSL服务器套接字 javax.net.ssl.SSLServerSocketFactory

ii. SSL会话：

iii. SSL环境与密钥管理器

1. 使用密钥管理器

2. 使用信任管理器

g) SSL的其他相关问题

i. SSL代理

ii. 客户端鉴别

iii. 选择SSL密码

iv. SSL握手

v. JSSE权限

h) HHTPS协议处理器

i. 验证HTTPS主机

ii. HTTPS属性

1. https.proxyHost

2. http.nonProxyHost

3. https.cipherSuites

iii. JSSE的调试

第十五章：鉴别与授权

a) JAAS提供了一个框架，开发人员可以要求执行其代码的用户必须有相应操作的权限。

b) JAAS提供了一组用于实现用户鉴别的类。支持JAAS的应用一般会要求用户登录，还提供了另一组类，用于授权用户执行某些特定的操作。

c) JAAS概述：

i. 程序要求用户登录，得到用户登录对象。

ii. 程序执行一个方法调用，并提供用户的登录对象，以代表用户执行的代码。

iii. 在刚创建的环境中，执行需要具体权限的代码。

iv. 对于开发人员，使用JAAS包括两步：必须发出一个调用以鉴别用户，然后代表该用户执行相应的方法。

v. 对于管理元，需要三步：首先配置一组登录模块，在配置一组JAAS策略文件，最后建立正确的程序执行环境。

d) 简单的JAAS程序设计：

i. LoginContext类

ii. Suject类

e) 简单的JAAS管理

i. 配置登录模块

1. Login control flags

a) Required

b) Sufficient

c) Requistite

d) Optional

2. Login control flags

a) Solaris 登录模块

b) NT登录模块

c) JNDI登录模块

3. Writting policy file

f) 高级JAAS技术

i. JAAS回调技术

1. 名字回调

2. 口令回调

3. 文本输入回调

4. 文本输出回调

5. 选择回调

6. 确认回调

7. 语言回调

g) 编写登录模块

h) JAAS Policy类

i) 管理JAAS策略

i. 客户/服务器鉴别

ii. 组与角色

 

JAVA SECURITY 2nd 算是读完了

真正属于java的内容 java沙箱， java securityManager classLoader accessControler 

其他的很多内容都是在第三方研究的基础上做了java方面的实现，并提供了相关的API 供别人使用，比如JCE ，java security provider，key and cert ,key Management (keytool and keystore) ,digest,data sign,SSL and HTTPS ,JAAS

Java Cryptography Extension (JCE) 

Public Key Infrastructure (PKI)

Java Authentication and Authorization Service (JAAS)

Java Secure Socket Extension (JSSE)

Java GSSAPI and Kerberos

Java SASL

XML Signature and Encryption

Tools

See Appendix for more info