专业论文翻译

专业 论文课题:Inside Encrypting File System 指 导 教 师: 史国军 班 级: 计算机2000,1, 姓 名: 刘海锋 报 告 时 间: 2004年6月01日 Inside Encrypting File System The next step EfsRpcEncryptFileSrv performs is to create a log file into which LSASRV will Record the progress of the encryption process.EfsRpcEncryptFileSrv creates the log file on the same drive as the file that EFS will encrypt, and places the log file under the root directory's subdirectory System Volume Information. The log file the name efs0.log, but if other files are undergoing usually has encryption, EfsRpcEncryptFileSrv replaces the number 0 with increasing numbers until LSASRV can create a unique log file for the current encryption.Win2K's cryptography APIs rely on information that a user's Registry profile stores, so EfsRpcEncryptFileSrv next uses the LoadUserProfile API of userenv.dll (User Environment DLL) to load the profile into the Registry of the user EfsRpcEncryptFileSrv is impersonating. Usually the user profile is already loaded, because winlogon.exe loads a user's profile when a However, if you use the Microsoft user interactively logs on. Windows NT Server 4.0 Resource Kit Su utility or the Win2K RunAs command to log on to a different account, when you try to access that account, the account's profile might not encrypted files from load.EfsRpcEncryptFileSrv's next step is to call another LSASRV function, EncryptFileSrv, to carry out the rest of the encryption process for the file. EncryptFileSrv begins by querying NTFS about which data streams exist within the file, noting the result for lateruse. NTFS supports alternate named data streams in addition to the default unnamed stream in which NT typically storesdata. Win2K makes heavy use of alternate streams to support compound document storage (i.e., Native Structured Storage), as does Services for Macintosh which uses alternate streams to implement Macintosh resource forks. EFS must encrypt all of a file's data streams—not just the stream that most applications see. EncryptFileSrv calls the internal function GenerateFEK to generate a FEK for the file.GenerateFEK uses the CryptoAPI function CryptAcquireContext to initiate a cryptographic session. CryptAcquireContext takes several parameters, includingthe name of the session's cryptographic provider and the cryptography service that the caller (inthis case, GenerateFEK) is interested in. GenerateFEKspecifies Microsoft Base Cryptographic Provider 1.0 as the session's cryptographic provider. GenerateFEK also signals that it wants to use the provider's RSA encryption facilities. Base Cryptographic Provider is a built-in provider that is present on all Win2K systems. However, the architecture of the CryptoAPI lets software vendors implement proprietary providers and dynamically add them to Win2K. Thus, GenerateFEK must specify a session's cryptographic provider. RSA is a public-key-based encryption algorithm tha has become a defacto worldwide standard. Thefile rsabase.dll implements RSA for BaseCryptographic Provider 1.0. After the CryptAcquireContext function returns with a handle to the provider,GenerateFEK calls CryptGenRandom to have the provider generate 16 bytes (128 bits) of random data to serve as the file's FEK. GenerateFEK then calls CryptCloseSession to close the cryptographic provider session, and returns control to EncryptFileSrv.Constructing Key Rings.At this point, EncryptFileSrv has a FEK and can construct EFS information to store with the file, including an encrypted version of the FEK. Figure 2 illustrates the EFS information's layout. EncryptFileSrv calls another function, ConstructEFS, to construct the EFS information. Before it can do so, ConstructEFS must use the CryptoAPI to get a handle to the user's public key and private key pair. To get this handle, ConstructEFS calls another function, GetCurrentKey, which reads the Registry value HKEY_CURRENT_USER\Software\ Microsoft\Windows NT\ CurrentVersion\ EF CertificateHash. Every public key/private key pair has S\CurrentKeys\ a digital certificate that the issuing certificate authority signs, and that users use to obtaintheir public keys. The digital signature, uniquely identifies the public key/private key pair. By or hash, reading the CertificateHash value, ConstructEFS obtains the current user's public key signature and uses it to access the public key and encrypt FEKs.When the CertificateHash value doesn't exist, which is the case the first time a user encrypts a file, EFS must determine whether the user has an EFS public key/private key pair, or whether it must create the key pair. First, EFS opens the My system certificate storage area, in which the OS stores EFS key pairs. (Several certificate storage areas can exist on a system, each containing various certificates.) EFS uses the CryptoAPI function CertFindCertirage area. If CertFindCertificateInStore doesn't find anEFS key-pair certificate, ConstructEFS calls GenerateUserKey to create one. GenerateUserKey calls CryptUIWizCertRequest to create thekey pair and return a signed certificate for the pair. The key-pair generation occurs on a domain controller (for a system that is part of a domain) or the local computer (for a computer that is not part of a domain). When EFS locates or creates the user's key-pair certificate, EFS obtains the certificate's hash and stores it in the Registry key HKEY_CURRENT_USER\ Software\Microsoft\Windows NT\CurrentVersion\ EFS\CurrentKeys\CertificateHash. In Win2K beta 3, the provider that creates public key/private key pairs is Base Cryptographic Provider 1.0. When it has the user's key-pair hash, EFS uses the CertGetCertificateContextProperty CryptoAPI to obtain information about the provider thatCACreateLocalAutoEnrollmentObject used to generate the key pair. This information includes the provider's name and the name of the container the provider uses to store key pairs for the user whom LSASRV is impersonating. The container name is meaningful only to theprovider, but in the case of Base Cryptographic Provider, the container name is a file path relative to the user's profile directory. An example container name is M:\Documents and Settings\Administrator\Application Data\Microsoft\SystemCertificates\My\Certificates\CD099602FD898D7EFCDC4283C6742D30A15A0062. Win2K hides the Application Data directory by default, and container filenames vary. EFS uses CryptAcquireContext to open a cryptographic session with theprovider. In the call to CryptAcquireContext, EFS specifies the provider name, the container name, and that it wants to use RSA encryption services. To obtain the current user's public key, EFS uses the function CryptExportKey, which causes the cryptographic provider to extract the key from the container.ConstructEFS can now construct the information that EFS stores with the file. The use of the user's public key LSASRV function ConstructKeyRing makes that CryptExportKey obtained to store the EFS information with a file.Microsoft calls the function ConstructKeyRing because, as I multiple users share encrypted files. EFSmentioned earlier, EFS lets stores only one block of information in an encrypted file, and that block contains an entry for each user sharing the file. These entries are called key entries, and EFS stores them in the Data Decryption Field (DDF) portion of the file's EFS data. A collection of multiple key entries is a key ring.Figure 2 shows a file's EFS information format and key entry format. EFS stores enough information in the first part of a key entry to precisely describe a user's public key. This data includes the cryptographic provider name, the container name in which the key is stored, the user's security ID (SID), and the public key/private key pair certificate hash. The second part of the key entry contains an encrypted version of the FEK. ConstructKeyRing uses the CryptEncrypt CryptoAPI to encrypt the FEK with the RSA algorithm and the user's public key. (When I describe the decryption process next month, I'll explain why EFS stores this information in key entries.)Next, EFS creates another keyring that contains recovery key entries. EFS stores information aboutrecovery key entries in a file's Data RecoveryField (DRF). The format of DRF entries is identical to the format of DDF entries. The DRF's purpose is to let designated accounts, or Recovery Agents, decrypt a user's file when administrative authority must have access to the user'sdata. For example, suppose a company employee used a CryptoAPI to store his private key on a smart card, then lost the card. Without Recovery Agents, no one could recover his encrypted data.You can define Recovery Agents with the Encrypted Recovery Agents security policy (which is a subset of public key policy) of The local computer or domain, as Screen 2 shows. When you use the Recovery Agent Wizard in the domain or computer management Microsoft Management Console (MMC) snap-in, you can add Recovery Agents and specify which public key/private key pairs (designated by their certificates)the agents use for EFS recovery. LSASRV interprets the recovery policy when it initializes and when it receives notificationthat the recovery policy has changed. EFS uses the cryptographic provider you register for EFS recovery to create a DRF key entry for each Recovery Agent. Currently, the default Recovery Agent provider is the RSA encryption facility of Base Cryptographic Provider 1.0— the same provider GenerateFEK uses for user keys.In the final step increating EFS information for a file, ConstructEFS uses the MD5 hash facility of Base Cryptographic Provider 1.0 to calculate a checksum for the DRF and DDF. EFS stores the checksum's result in the EFS information header. EFS references this checksum during decryption to the contents of a file's EFS information have not become ensure that corrupted or been tampered with. Screen 3 shows an encrypted file's $EFS attribute's on-disk contents. Some of the fields I've described name of the cryptographic store that are highlighted, including the stores the key pair the encryption uses (the string beginning 5.d.c.3.b.3.e.b.-.5.), the name of the cryptographic provider (Microsoft Base Cryptographic Provider v1.), and information used for display when applications query the encryption format (L.=.E.F.S.). DiskEdit,the utility viewing the data in Screen 3, is an unsupported tool thatMicrosoft includes on the Service Pack 4 (SP4) CD-ROM.To Be Continued That brings us to the end of this month's column. Next month, I'll conclude my description of the encryption process, and I'll describe the file decryption process and some of the other EFS APIs that LSASRV supports. 加密文件系统 下一个步骤 EfsRpcEncryptFileSrv 表演乃是创作其 LSASRV 希望的一个记录文件记录编密码过程的进展。EfsRpcEncryptFileSrv 创作记录文件上作为 EFS 将加密，在根本目录下面的地方记录文件是的文件的同样的行驶子目录系统卷信息。记录文件通常有名字 efs0.log，但是如果其他文件在经受编密码， EfsRpcEncryptFileSrv 取代数字 0 通过增加直到 LSASRV 的数字能够创建一个独特的记录文件当前的 encryption.Win2K 是密码术 APIs 依赖一个用户的登记处简介储存的信息，所以 EfsRpcEncryptFileSrv 紧接着使用 userenv.dll 的 LoadUserProfile API(用户环境 DLL)装简介进用户 EfsRpcEncryptFileSrv 的登记处人格化。通常用户简介已经被装，因为 winlogon.exe 装一个用户的简介当一个用户交互地登录。可是，如果你使用微软 Windows NT 服务器 4.0资源个人装具 Su 设施或者到一个不同的理由登录的 Win2K RunAs 指挥，当你尝试从那个报告使用被加密的文件的时候，账户的简介可能不装货。EfsRpcEncryptFileSrv 的下一个步骤乃是叫另一种 LSASRV 功能，EncryptFileSrv，为了运载向外用于文件的编密码过程的其余部分。 NTFS 数据溪在文件以内存在，注意用于更迟的EncryptFileSrv 通过询问关于 使用的结果的 NTFS 开始。NTFS 支持交替除了缺省值之外被命名是数据溪无名的溪在那 NT 典型地 storesdata。Win2K 做出交换的溪的大量使用支持复合的文件存储器(即，本地被组织的存储器)，正如为了使用交换的溪实现的 Macintosh 服务Macintosh 资源不情愿地交付。EFS 必须加密所有一份文件的数据 streams 梟ot 刚刚溪那大多数申请明白。EncryptFileSrv 叫内在的功能 GenerateFEK 产生一 FEK对 file.GenerateFEK 使用 CryptoAPI 功能 CryptAcquireContext 为了开始用密码写的会议。CryptAcquireContext 接受若干参数，包括会议的用密码写的提供者的名字和密码术服务那访问者(在这种情况下， GenerateFEK)是对有兴趣。GenerateFEKspecifies 微软基础用密码写 提供者作为会议的用密码写的提供者的 1.0。GenerateFEK 也发信号那它想使用提供者的英国 rsa 实验室编密码设施。基本用密码写的提供者是在所有 Win2K 系统上是未缺失的一个固定的提供者。可是 CryptoAPI 的建筑让软件公司实现私人的提供者和动态地把他们加到 Win2K 上。这样， GenerateFEK 必须标示一届会议的用密码写的提供者。英国 rsa 实验室是一个公众为定基调基于的编密码算法 tha 成为一个事实上世界范围的标准。文件 rsabase.dll 因为 BaseCryptographic Provider 1.0.After 实现英国 rsa 实验室 CryptAcquireContext 功能用到提供者的一个把柄归来，GenerateFEK 给 CryptGenRandom 打电话有提供者产生 16 个字节(128 少量)担任文件的 FEK 的随便的数据中。GenerateFEK 然后把 CryptCloseSession 叫到结束用密码写的提供者会议，归还控制到 EncryptFileSrv.Constructing 钥匙圈。在这一点上， EncryptFileSrv 有一 FEK 和能够构思 EFS 信息跟包括 FEK 的一个被加密的版本在内的文件一起储存。图 2 说明 EFS信息的规划。EncryptFileSrv 叫另一种功能， ConstructEFS，建造 EFS信息。在它能够这样做以前， ConstructEFS 必须使用 CryptoAPI 得到一个把柄到用户的公共主要和私人主要的对。为了得到这个把柄， ConstructEFS 叫另一种功能，GetCurrentKey，读登记处价值 HKEY_CURRENT_USER \ 软件 \ 微软 \ Windows NT \ CurrentVersion \ EFS \ CurrentKeys \ CertificateHash。每把公共主要/私营钥匙对有发行证书权力签名，用户使用弄到的一份数字证书他们的公共的钥匙。数字签名，或者杂乱信号，独特地识别公共主要/私营钥匙对。通过读 CertificateHash 价值， ConstructEFS 弄到当前的用户的公共的钥匙签名和使用它使用公共的钥匙，加密 FEKs.When CertificateHash 价值不存在，是一个用户加密的案例第一次一份文件， EFS 必须决定是否用户有一 EFS 公众钥匙/列兵钥匙对，或者是否它必须创造主要的对。第一， EFS打开我的系统证书存储器地区，在那 OS 商店 EFS 钥匙配对。(一些证书存储器地区能够在一个系统上存在，每一个控制不同的证书。) EFS 使用 CryptoAPI 功能 CertFindCertirage 地区。如果 CertFindCertificateInStore 不找到一 EFS 主要对的证书， ConstructEFS 给 GenerateUserKey 打电话创建一个。GenerateUserKey 叫喊CryptUIWizCertRequest 为了创造主要的对，归来对的一份被签名的证书。主要对的一代在一个领域控制器上出现(对是领域部分的一个系统)或者本地计算机(对不是领域部分的一台计算机)。当 EFS 定居或者创造的时候用户的主要对的证书， EFS 弄到证书的杂乱信号和在登记处钥匙中储存它HKEY_CURRENT_USER \ 软件 \ 微软 \ Windows NT \ CurrentVersion \ EFS \CurrentKeys \ CertificateHash .在 Win2K beta 中 3，创造公共主要/ 1.0。当它有用户的主要对的杂乱私营钥匙的提供者对是基本用密码写的提供者 信号的时候， EFS 使用 CertGetCertificateContext 财产 CryptoAPI 弄到关于提供者的信息那CACreateLocalAutoEnrollmentObject 常产生主要的对。这条信息包括提供者的名字和提供者使用把主要的对保存以供用户的容器的名字谁 LSASRV 人格化。容器名字对于提供者是有意义唯一的，但是在基本用密码写例的提供者，容器名字是一条文件路径与有关系用户是简介目录。一个例子容器名字是 M:\Documents 和设置 \ 主管 \申请数据 \ 微软 \ SystemCertificates \ 我的 \ 证书 \CD099602FD898D7EFCDC4283C6742D30A15A0062 .Win2K 隐藏申请数据由缺省值，和容器文件名所作的目录变化。EFS 使用 CryptAcquireContext 开放带提供者的用密码写的会议。在到 CryptAcquireContext， EFS 的电话标示提供者名字，容器名字，那它想使用英国 rsa 实验室编密码服务。为了弄到当前的用户的公共的钥匙， EFS 使用功能 CryptExportKey，导致从 container.ConstructEFS 抽取钥匙的用密码写的提供者现在能够建造EFS 跟文件一起储存的信息。LSASRV 功能 ConstructKeyRing 利用 CryptExportKey 弄到跟一份文件一起储存 EFS 信息的用户的公共的钥匙。微软叫功能 ConstructKeyRing 因为，当我更早提及， EFS 让多的用户分享被加密的文件。EFS 在一份被加密的文件中储存信息的仅仅一街区，那条街区为分享文件的每个用户包含进入。这些进入叫做主要的进入，以及 EFS 在数据中储存他们 Decryption 菲尔德(DDF)文件的 EFS 数据的部分。多主要的进入的收集是一主要的 ring.Figure 2 次展览会一份文件的 EFS 信息格式和为进入格式定基调。EFS 在头一个中储存足够信息主要的进入部分到精确描写一个用户的公共的钥匙。这数据包括用密码写的提供者名字，容器在其钥匙储存的名字用户的安全身份证 (SID)，公共主要/私人主要的对证书杂乱信号。第二个主要的进入部分包含 FEK 的一个被加密的版本。ConstructKeyRing 使用 CryptEncrypt CryptoAPI 有英国 rsa 实验室算法加密 FEK 和用户的公共的钥匙。(当我描写译码解码过程下月的时候，我将解释为什么EFS 在主要的条目中储存这条信 息。)下一个， EFS 创造包含的另一个钥匙圈恢复钥匙进入。EFS 储存关于恢复钥匙进入的信息在一份文件中是数据 RecoveryField(DRF)。DRF 进入的格式等同于 DDF 进入的格式。 DRF 的目的乃是让被指定的报告，或者恢复代理人，解密一个用户的文件当 行政的权力必须可接触到 user'sdata。例如，猜想一家公司雇员使用一 CryptoAPI 在一张智能卡上储存他的私营钥匙，然后失掉卡片。无恢复代理人，没人能够重新获得他的被加密的 data.You 能够定义恢复代理人带被加密的恢复代理人安全政策(那是公共主要的政策的一个子集)本地计算机或者领域，如屏幕 2 次展览会。当你使用恢复代理人向导的时候在领域或者计算机管理微软管理控制台 (MMC) 猛咬在，你能够补充说恢复代理人和说明哪个公共主要/私营钥匙配对(按他们的证明指定)代理人使用对 EFS 恢复。LSASRV 在它初始化时解释恢复政策和当它获得恢复政策改变了的通知的时候。EFS 使用用密码写你为其注册的提供者 EFS 为每个恢复代理人创造 DRF 钥匙进入的恢复。目前，缺省值恢复代理人提供者是基础的英国 rsa 实验室编密码设施用密码写的提供者 1.0 梩he 同样的事提供者 GenerateFEK 使用对用户钥匙。在最后的步骤中在因为一份文件创作 EFS 信息方面， ConstructEFS 使用基本用密码写的提供者的 MD5 杂乱信号设施 1.0 为了为了 DRF 和 DDF 计算一个检查机检验和。EFS EFS 信息标题方面的检查机检验和的结果。EFS 在译码解码期间提出这储存在 个检查机检验和作参考确保那一份文件的 EFS 信息的目录没有成为堕落或者 被篡改带。屏幕 3 次展览会一份被加密的文件是 $ EFS 属性的碟片的目录。中的几个我描写了的地被突出，包括储存编密码使用的主要的对的用密码写的商店的名字(线起点 5.d.c.3.b.3.e.b.-.5。)，名字用密码写的提供者(微软基础用密码写的提供者 v1。)，信息用来展示当申请询问编密码格式的时候(L. = .E.F.S.)。DiskEdit，看的设施在电影业中的数据 3，是微软在服务压缩包包括的一件无支持的工具 4(SP4)CD-ROM.To 被继续那把我们带给这个月的专栏的终止。下个月，我将结束我的编密码过程的描写，我将描写文件译码解码过程和某些其他的 EFS LSASRV 支持的 APIs。