




已閱讀5頁,還剩60頁未讀, 繼續(xù)免費閱讀
版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)
文檔簡介
.,第13章安全協(xié)議,.,主要內(nèi)容,安全協(xié)議概述IPsec協(xié)議SSL協(xié)議安全電子交易協(xié)議SET,.,13.1安全協(xié)議基本概念,協(xié)議協(xié)議是指兩個或多個以上參與者為完成某項特定的任務而采取的一系列步驟。通信協(xié)議通信協(xié)議是指通信各方關(guān)于通信如何進行所達成的一致性規(guī)則,即由參與通信的各方按確定的步驟做出一系列通信動作,是定義通信實體之間交換信息的格式及意義的一組規(guī)則。包括語法、語義和同步三大要素。,.,安全協(xié)議基本概念,安全協(xié)議安全協(xié)議是指通過信息的安全交換來實現(xiàn)某種安全目的所共同約定的邏輯操作規(guī)則。網(wǎng)絡安全通信協(xié)議屬于安全協(xié)議,是指在計算機網(wǎng)絡中使用的具有安全功能的通信協(xié)議。,.,TCP/IP安全分析,由于TCP/IP協(xié)議簇在早期設(shè)計時是以面向應用為根本目的的,因此未能充分考慮到安全性及協(xié)議自身的脆弱性、不完備性,導致網(wǎng)絡中存在著許多可能遭受攻擊的漏洞。,.,TCP/IP安全分析,網(wǎng)絡層協(xié)議的安全隱患IP協(xié)議在實現(xiàn)通信的過程中并不能為數(shù)據(jù)提供完整性和機密性保護,缺少基于IP地址的身份認證機制,容易遭到IP地址欺騙攻擊。傳輸層協(xié)議的安全隱患TCP協(xié)議的安全隱患:服務器端維持大量的半連接列表而耗費一定的資源。序列號可計算UDP協(xié)議的安全隱患不確認報文是否到達不進行流量控制不作糾錯和重傳,.,TCP/IP安全分析,應用層協(xié)議的安全隱患大部分協(xié)議以超級管理員的權(quán)限運行,一旦這些程序存在安全漏洞且被攻擊者利用,極有可能取得整個系統(tǒng)的控制權(quán)。許多協(xié)議采用簡單的身份認證方式,并且在網(wǎng)絡中以明文方式傳輸。,.,TCP/IP的安全體系結(jié)構(gòu),.,13.2IPsec協(xié)議,IPsec(IPSecurity)產(chǎn)生于IPv6的制定之中,用于提供IP層的安全性。IPsec(InternetProtocolSecurity,Internet協(xié)議安全)通過AH(AuthenticationHeader,驗證報頭)和ESP(EncapsulatingSecurityPayload,封裝安全有效負載)兩個安全協(xié)議分別為IP協(xié)議提供了基于無連接的數(shù)據(jù)完整性和數(shù)據(jù)保密性。,.,基本概念和術(shù)語,安全關(guān)聯(lián)為了正確封裝和提取IPsec的數(shù)據(jù)包,有必要采取一套專門的方案,將安全服務、密鑰等與要保護的通信數(shù)據(jù)聯(lián)系在一起,這樣的構(gòu)建方案稱為安全關(guān)聯(lián)(SecurityAssociation,SA)。SA是發(fā)送者和接收者兩個IPsec系統(tǒng)之間的一個單向邏輯連接,若要在一個對等系統(tǒng)間進行源和目的的雙向安全通信,則需要兩個SA。安全關(guān)聯(lián)SA通過一個三元組(安全參數(shù)索引SPI、目的IP地址和安全協(xié)議AH或ESP)來唯一標識。實現(xiàn)IPsec必須維護這兩個數(shù)據(jù)庫:安全策略數(shù)據(jù)庫:對所有出/入業(yè)務應采取的安全策略安全關(guān)聯(lián)數(shù)據(jù)庫:為進入和外出包處理維持一個活動的SA列表,.,基本概念和術(shù)語,隧道把一個包封裝在另一個新包中,整個源數(shù)據(jù)包作為新包的有效載荷部分,并在前面添加一個新的IP頭。對IPsec而言,IP隧道的直接目標就是對整個IP數(shù)據(jù)包提供完整的保護。Internet安全關(guān)聯(lián)和密鑰管理協(xié)議InternetSecurityAssociationandKeyManagementProtocol,ISAKMP為Internet環(huán)境下安全協(xié)議使用的安全關(guān)聯(lián)和密鑰的創(chuàng)建定義了一個標準通用框架,定義了密鑰管理表述語言通用規(guī)則及要求。,.,基本概念和術(shù)語,解釋域DomainofInterpretation,DOI是Internet編號分配機構(gòu)IANA給出的一個命名空間。為使用ISAKMP進行安全關(guān)聯(lián)協(xié)商的協(xié)議統(tǒng)一分配標識符。共享一個DOI的協(xié)議從一個共同的命名空間中選擇安全協(xié)議和密碼變換、共享密鑰以及交換協(xié)議標識符等,從而能使用相同DOI的協(xié)議對該DOI下的載荷數(shù)據(jù)內(nèi)容做出統(tǒng)一的解釋。,.,IPsec組成,AuthenticationHeader(AH,驗證報頭)協(xié)議定義了認證的應用方法,提供數(shù)據(jù)源認證和完整性保證;EncapsulatingSecurityPayload(ESP,封裝安全有效負載)協(xié)議定義了加密和可選認證的應用方法,提供可靠性保證。InternetKeyExchange(IKE,密鑰的交換標準)協(xié)議。用于密鑰交換。,.,AH協(xié)議,AH的工作原理:在每一個數(shù)據(jù)包上添加一個身份驗證報頭。此報頭包含一個被加密的hash值(可以將其當作數(shù)字簽名,只是它不使用證書),此hash值在整個數(shù)據(jù)包中計算,因此對數(shù)據(jù)的任何更改將導致hash值無效,這樣就提供了完整性保護。AH報頭位置在IP報頭和傳輸層協(xié)議頭之間。AH由協(xié)議號“51”標識,.,AH報頭結(jié)構(gòu),.,(1)下一個頭(NextHeader):8位,標識下一個使用IP協(xié)議號的報頭類型,其取值在RFC1700中定義。(2)載荷長度(PayloadLength):8位,表示以32位為單位的AH頭的長度減2。(3)保留(Reserved):16位,供將來使用。值為0。(4)安全參數(shù)索引(SecurityParametersIndex,SPI):這是一個為數(shù)據(jù)報識別安全關(guān)聯(lián)SA的32位偽隨機值。(5)序列號(SequenceNumber):從1開始的32位單增序列號,不允許重復,唯一地標識了每一個發(fā)送數(shù)據(jù)包,為安全關(guān)聯(lián)提供反重播保護。(6)認證數(shù)據(jù)(AuthenticationData,AD):長度可變,但必須是32位的整數(shù)倍,默認長度為96位。包含了數(shù)據(jù)包的完整性校驗值ICV。,.,ESP協(xié)議,ESP的作用是提供機密性保護、有限的流機密性保護、無連接的完整性保護、數(shù)據(jù)源認證和抗重放攻擊等安全服務。ESP提供和AH類似的安全服務,但增加了數(shù)據(jù)機密性保護和有限的流機密性保護等兩個額外的安全服務。ESP可以單獨使用,也可以和AH結(jié)合使用。一般ESP不對整個數(shù)據(jù)包加密,而是只加密IP包的有效載荷部分,不包括IP頭。但在端對端的隧道通信中,ESP需要對整個數(shù)據(jù)包加密。,.,ESP數(shù)據(jù)包格式,認證覆蓋范圍,保密性覆蓋范圍,08162431,安全參數(shù)索引,序列號,認證數(shù)據(jù),載荷數(shù)據(jù)(變長),下一個頭,填充項長度,填充項,.,(1)安全參數(shù)索引(SPI):32位整數(shù)。它和IP頭的目的地址、ESP協(xié)議一起用以唯一標識對這個包進行ESP保護的SA。(2)序列號(SequenceNumber):從1開始的32位單增序列號,不允許重復,唯一地標識了每一個發(fā)送數(shù)據(jù)包(3)載荷數(shù)據(jù):長度不固定,所包含的是由下一個頭字段所指示的數(shù)據(jù)(如整個IP數(shù)據(jù)包、上層協(xié)議TCP或UDP報文等)(4)填充項(Padding):如果加密算法要求明文是某個數(shù)字的整數(shù)倍,則通過填充可將明文擴充到所需要的長度。另外,通過填充可以隱藏載荷數(shù)據(jù)的實際長度,從而對流量提供部分的保密性。(5)填充項長度(PaddingLength):8位,表明填充項字段中填充以字節(jié)為單位的長度。(6)下一個頭(NextHeader):識別下一個使用IP協(xié)議號的報頭,如TCP或UDP。(7)認證數(shù)據(jù)(AuthenticationData):長度不固定,存放的是完整性校驗值ICV。,.,IKE協(xié)議,IKE的基礎(chǔ)是ISAKMP,Oakley和SKEME三個協(xié)議,它沿用了ISAKMP的基礎(chǔ),Oakley的模式以及SKEME的共享和密鑰更新技術(shù)。使用了兩個交換階段,階段一用于建立IKESA,階段二利用已建立的IKESA為IPsec協(xié)商具體的一個或多個安全關(guān)聯(lián),即建立IPsecSA。IKE允許四種認證方法,分別是基于數(shù)字簽名的認證、基于公鑰加密的認證、基于修訂的公鑰加密的認證和基于預共享密鑰的認證。,.,IPsec的工作模式,傳輸模式采用傳輸模式時,原IP數(shù)據(jù)包的首部之后的數(shù)據(jù)會發(fā)生改變,通過增加AH或ESP字段來提供安全性,但原IP首部不變。AH傳輸模式ESP傳輸模式隧道模式隧道模式的保護對象是整個IP包。在AH或ESP字段加入到IP分組后,還要加上一個新的首部,原數(shù)據(jù)包加上安全字段成為新數(shù)據(jù)包的載荷,因此得到了完全的安全性保護。AH隧道模式ESP隧道模式,.,AH傳輸模式,除變長字段外都要認證,AH傳輸模式下IPv4封包:,原IPv4封包:,IP頭,TCP/UDP頭,數(shù)據(jù),原IP頭,TCP/UDP頭,數(shù)據(jù),AH頭,.,ESP傳輸模式,加密,ESP傳輸模式下IPv4封包:,原IPv4封包:,IP頭,TCP/UDP頭,數(shù)據(jù),原IP頭,TCP/UDP頭,數(shù)據(jù),ESP頭,ESP尾部,ESP認證數(shù)據(jù),認證,.,AH隧道模式,除新IP頭變長字段外都要認證,原IPv4封包:,IP頭,TCP/UDP頭,數(shù)據(jù),AH傳輸模式下IPv4封包:,新IP頭,AH頭,原IP頭,TCP/UDP頭,數(shù)據(jù),.,ESP隧道模式,加密,ESP傳輸模式下IPv4封包:,原IPv4封包:,IP頭,TCP/UDP頭,數(shù)據(jù),新IP頭,TCP/UDP頭,數(shù)據(jù),ESP頭,ESP尾部,ESP認證數(shù)據(jù),認證,原IP頭,.,IPsec的應用,目前IPsec最主要的應用就是構(gòu)建安全的虛擬專用網(wǎng)。虛擬專用網(wǎng)(VirtualPrivateNetwork,VPN)是一條穿過公用網(wǎng)絡的安全、穩(wěn)定的隧道。通過對網(wǎng)絡數(shù)據(jù)的封包和加密傳輸,在一個公用網(wǎng)絡(通常是因特網(wǎng))建立一個臨時的、安全的連接,從而實現(xiàn)在公網(wǎng)上傳輸私有數(shù)據(jù),達到私有網(wǎng)絡的安全級別。,.,基于IPsec的VPN,.,IPSecVPN的不足,最早出現(xiàn)的具有加密功能的VPN是IPSecVPN。雖然IPSecVPN簡單高效,但在實現(xiàn)遠程接入時存在以下一些弱點:網(wǎng)絡的互聯(lián)性不好客戶端使用和維護困難訪問權(quán)限管理粒度較粗,.,SSLVPN產(chǎn)生的背景,對于IPSecVPN在實現(xiàn)遠程接入方面存在的問題,SSLVPN可以很好地給予解決:網(wǎng)絡互聯(lián)性:SSL工作在TCP層,不會受NAT和防火墻的影響??蛻舳说木S護:借助瀏覽器,實現(xiàn)客戶端的自動安裝和配置。訪問權(quán)限管理:解析應用層協(xié)議,進行高細粒度地訪問控制。,.,13.3SSL協(xié)議,SSL協(xié)議是一個傳輸層安全協(xié)議。SSL協(xié)議由Netscape公司于1994年11月提出并率先實現(xiàn),即SSLV2.0Internet-Draft版本1996年3月推出了SSLV3.0Internet-Draft版本,最終被IETF所采納,并制定為傳輸層安全標準。工作在傳輸層之上,應用層之下,其底層是基于傳輸層可靠的流傳輸協(xié)議(如TCP),.,SSL協(xié)議簡介,SSL:英文“SecureSocketLayer”,中文“安全套接字”協(xié)議。SSL協(xié)議是一種工作在TCP層之上的,用于安全傳輸數(shù)據(jù)的加密協(xié)議。SSL協(xié)議可以提供以下功能:加密的數(shù)據(jù)傳輸支持用數(shù)字簽名驗證通訊雙方的身份抗攻擊,如重播(replay)、中間人(man-in-middle)等。面向應用程序的API接口,便于SSL協(xié)議在客戶端和服務器端部署。,.,SSL協(xié)議簡介工作模型,SSL協(xié)議在使用方面的特點:SSL協(xié)議對上層應用提供端到端的,有連接的加密傳輸服務。SSL協(xié)議采用了C/S架構(gòu)的通訊模式。SSL服務器端作為一種TCP服務,監(jiān)聽443號端口,接收建立SSL連接的請求報文。,.,SSL協(xié)議簡介協(xié)議架構(gòu),SSL協(xié)議包含兩層:握手層:負責建立SSL連接記錄層:負責對報文進行加解密,.,SSL協(xié)議簡介記錄層,SSL記錄層提供下列功能:保證數(shù)據(jù)傳輸?shù)乃矫苄?。對傳輸?shù)據(jù)進行加密和解密。保證數(shù)據(jù)傳輸?shù)耐暾浴S嬎愫万炞C報文的消息驗證碼。對傳輸數(shù)據(jù)的壓縮。目前壓縮算法為空。對上層提供可靠保序的有連接服務。,加密數(shù)據(jù),報文類型,版本,長度,長度(字節(jié)),1字節(jié),2字節(jié),2字節(jié),MAC,報文類型:密鑰改變協(xié)議(20),告警協(xié)議(21),握手協(xié)議(22),應用層數(shù)據(jù)(23)版本:TLS1.0(3,1),SSL3.0(3,0)長度:記錄層報文的長度,包括加密數(shù)據(jù)和MAC值的字節(jié)數(shù)。MAC:整個記錄報文的消息驗證碼,包括從報文類型開始的所有字段。,SSL記錄層的報文格式:,.,SSL協(xié)議簡介握手層,SSL握手層提供下列功能:協(xié)商加密能力協(xié)議版本、加密套件、壓縮算法。協(xié)商密鑰參數(shù):塊加密:初始化向量(IV)、加密密鑰、HMAC密鑰。流加密:流初始狀態(tài)、HMAC密鑰。驗證對方身份(可選)建立并維護SSL會話,.,SSL協(xié)議簡介握手過程,SSL握手協(xié)議提供了三種握手過程:無客戶端身份認證的全握手過程全握手過程是指一個完整的SSL連接建立過程,在其中需要協(xié)商出新的會話參數(shù)?!盁o客戶端認證”是指在該過程中服務器端并不驗證客戶端的身份。有客戶端身份認證的全握手過程服務器端可以通過此過程利用數(shù)字簽名來驗證用戶的真實身份。會話恢復過程由于SSL全握手過程涉及到較多的復雜計算,耗時較多。為提高建立SSL連接的效率,SSL協(xié)議提供了會話恢復機制,使得后面建立的SSL連接可以利用以前連接的會話參數(shù),避免了重新協(xié)商的過程。,.,SSL協(xié)議簡介無客戶端認證的全握手過程,client,server,ClientHello,ServerHello,ServerCertificate*,ServerKeyExchange*,ServerHelloDone*,ChangeCipherSpec,Finished,ApplicationData,客戶端支持的最高版本,加密套件列表,壓縮算法列表,客戶端隨機數(shù),會話ID=0,服務器同意的版本,加密套件,壓縮算法、會話ID、服務器端隨機數(shù),服務器的證書,服務器端密鑰交換的附加信息,通知對方服務器端握手消息發(fā)完,客戶端產(chǎn)生的PreMasterKey密鑰參數(shù),通知對方本端開始啟用加密參數(shù),通知對方本端開始啟用加密參數(shù),發(fā)送客戶端計算握手過程的驗證報文,發(fā)送自己計算握手過程驗證報文,傳送應用層數(shù)據(jù),ClientKeyExchange,Finished,ApplicationData,ChangeCipherSpec,.,SSL協(xié)議簡介有客戶端認證的全握手過程,.,SSL協(xié)議簡介會話恢復過程,.,SSL安全協(xié)議主要提供三方面的服務,客戶和服務器的合法性認證加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)保護數(shù)據(jù)的完整性,.,SSL安全通信過程,(1)接通階段:客戶機通過網(wǎng)絡向服務器打招呼,服務器回應;(2)密碼交換階段:客戶機與服務器之間交換雙方認可的密碼,一般選用RSA密碼算法,也有的選用Diffie-Hellmanf和Fortezza-KEA密碼算法;(3)會談密碼階段:客戶機與服務器間產(chǎn)生彼此交談的會談密碼;(4)檢驗階段:客戶機檢驗服務器取得的密碼;(5)客戶認證階段:服務器驗證客戶機的可信度;(6)結(jié)束階段:客戶機與服務器之間相互交換結(jié)束的信息。,.,SSL協(xié)議的分層結(jié)構(gòu),SSL協(xié)議具有兩層結(jié)構(gòu),其底層是SSL記錄協(xié)議層(SSLRecordProtocolLayer),簡稱記錄層。其高層是SSL握手協(xié)議層(SSLHandshakeProtocolLayer),簡稱握手層。,.,會話與連接,Connection(連接):一個在傳輸層協(xié)議上的傳輸媒介,它提供一個適當?shù)姆铡_B接建立在會話的基礎(chǔ)上,每個連接與一個會話相關(guān)聯(lián),并對應到一個會話。Session(會話):SSL會話建立客戶與服務器之間的一個關(guān)聯(lián)(Association)。每一組客戶端與服務器之間就是一個SSLsession。這些會話定義一組以密碼為基礎(chǔ)的安全性參數(shù),這些參數(shù)能夠由多個連接來共同使用。,會話,.,SSL握手協(xié)議,Handshake協(xié)議用來讓客戶端及服務器確認彼此的身份。協(xié)助雙方選擇連接時所使用的加密算法、MAC算法、及相關(guān)密鑰。Handshake由一些客戶與服務器交換的消息所構(gòu)成,每一個消息都含有以下三個字段:類型(Type),1個字節(jié):表示消息的類型,總共有十種。長度(Length),3個字節(jié):消息的位組長度。內(nèi)容(Content),大于或等于1個字節(jié),與此消息有關(guān)的參數(shù)。,.,SSLHandshake協(xié)議消息類型,.,客戶端與服務器產(chǎn)生一條新連接所要進行的初始交換過程包括四個階段,即建立安全能力、服務器認證與密鑰交換、客戶端認證與密鑰交換、完成。,.,SSL記錄協(xié)議,SSL記錄協(xié)議為每一個SSL連接提供以下兩種服務:機密性(Confidentiality):SSL記錄協(xié)議會協(xié)助雙方產(chǎn)生一把共有的密鑰,利用這把密鑰來對SSL所傳送的數(shù)據(jù)做傳統(tǒng)式加密。消息完整性(MessageIntegrity):SSL記錄協(xié)議會協(xié)助雙方產(chǎn)生另一把共有的密鑰,利用這把密鑰來計算出消息認證碼。,.,SSL記錄協(xié)議運作模式,.,SSL協(xié)議安全性分析,SSL協(xié)議自身的缺陷客戶端假冒SSL協(xié)議無法提供基于UDP應用的安全保護SSL協(xié)議不能對抗通信流量分析針對基于公鑰加密標準(PKCS)協(xié)議的自適應選擇密文攻擊進程中的主密鑰泄漏磁盤上的臨時文件可能遭受攻擊,.,SSL協(xié)議安全性分析,不規(guī)范應用引起的問題對證書的攻擊和竊取中間人攻擊安全盲點IE瀏覽器的SSL身份鑒別缺陷,.,SSLVPN與IPSecVPN的比較,.,13.4安全電子交易協(xié)議SET,SET協(xié)議(SecureElectronicTransaction,安全電子交易)是由VISA和MasterCard兩大信用卡公司聯(lián)合推出的規(guī)范。SET主要是為了解決用戶、商家和銀行之間通過信用卡支付的交易而設(shè)計的,以保證支付命令的機密、支付過程的完整、商戶及持卡人的合法身份,以及可操作性。SET中的核心技術(shù)主要有公鑰加密、數(shù)字簽名、數(shù)字信封、數(shù)字證書等。SET是應用層的安全協(xié)議。,.,SET提供的服務,給所有參與交易的每一方提供一個安全的通信管道。使用X.509v3數(shù)字證書來提供可信賴的服務。確保交易的隱密性。唯有必要的時候,才會在必要的場所提供給交易雙方所需的信息。,.,SET交易分為三個階段,第一階段為購買請求階段,持卡人與商家確定所用支付方式的細節(jié)第二階段是支付的認定階段,商家與銀行核實,隨著交易的進行,他們將得到支付第三階段為收款階段,商家向銀行出示所有交易的細節(jié),然后銀行以適當方式轉(zhuǎn)移貨款。在整個交易過程中,持卡人只和第一階段有關(guān),銀行與第二、第三階段有關(guān),而商家與三個階段都要發(fā)生聯(lián)系。每個階段都要使用不同的加密方法對數(shù)據(jù)加密,并進行數(shù)字簽名。,.,SET交易的參與者,SET規(guī)范的交易模式中,所參與的個體包括持卡人、特約商店、發(fā)卡行、收單行、支付網(wǎng)關(guān)、認證中心等。,.,進行一個SET交易所經(jīng)歷的事件,(1)消費者開立賬戶(2)消費者收到證書(3)特約商店證書(4)消費者訂購(5)特約商店核對(6)發(fā)送訂單及支付(
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 項目簽約協(xié)議書范本
- 草場租賃與生態(tài)補償機制協(xié)議
- 企業(yè)車輛事故責任免除與賠償協(xié)議
- 青島商鋪租賃協(xié)議書范本
- 綠色節(jié)能彩鋼活動房安裝施工安全保證合同
- 高端公寓租賃管理合同范本
- 中外合資餐飲品牌開發(fā)與推廣協(xié)議
- 草籽種植補貼與購銷保障合同
- 橋梁模態(tài)分析試驗專題報告
- 餐飲部管理運轉(zhuǎn)手冊
- 期末綜合試題 2024-2025學年下期初中英語人教版七年級下冊(新教材)
- 高中生物學業(yè)水平合格性考試:人教版必修1+必修2必背考點
- 安全生產(chǎn)應急演練方案(合集)
- 2025江蘇揚州寶應縣“鄉(xiāng)村振興青年人才”招聘67人筆試模擬試題含答案詳解
- 2025年甘肅高考真題化學試題(解析版)
- 中國政法大學《中國政治制度史》2023-2024學年第二學期期末試卷
- 超高玻璃吊裝方案(3篇)
- 2025年中考物理壓軸題分類匯編:單選題(電功率和電與磁綜合49題)原卷版+解析
- 東航java面試題及答案編程
- 醫(yī)學影像讀片試題及答案
- API RP 1175-2022 管道泄漏檢查計劃管理
評論
0/150
提交評論