區塊鏈應用的密鑰管理
管理什么密鑰？
在區塊鏈應用的基礎組件中通常有這樣一種功能，需要持續不斷的向區塊鏈中發送交易，比如arbitrum的Sequencer需要持續不斷的發送L2的區塊，stark 需要發送單步證明/rBlock發布 的交易，chainlink需要定時發送datafeed交易。而這每一筆交易都需要L1上的賬戶做簽名，如何安全的使用和管理這個密鑰是值得關心的。
結論
就我所看到的一般有兩種方式：
- 通過配置文件配置私鑰
- 使用filekey的方式：
- 注意file一般需要一個密碼，密碼是啟動后在終端控制臺輸入
當然，密鑰管理不只是簡單的將密鑰注入到程序里面，而是如何在程序里面安全的使用這些密鑰，畢竟如果密鑰發在一個可能被外部接口調用的接口中，可能會降低密鑰的安全性。
密鑰安全等級（依次遞減，只考慮加密算法公開的情況）：
- 黑客無法得知任何明文&密文
- 黑客可以得到密文
- 黑客可以得到密文對應的明文
- 黑客可以自行構造明文產生密文
所以在程序中也需要對密鑰進行保護。
以太坊中每次使用完私鑰會將私鑰的地址還原成0地址，就是為了避免私鑰在內存中泄漏。
私鑰泄漏的原理大致是，geth程序在使用玩內存后會釋放內存，而他釋放內存并不會把內存值全部置0,而只是告訴操作系統，“這段內存我不用了，你可以分配給別的程序” 。而別的程序申請到這段內存之后，他是可以直接讀取這段內存里的值，（經典案例就是 在c語言中如果你初始化一個變量，而不為賦值，那他的值不是0值，而是原先在這個值里面的內存的值）
arbitrum的處理方案
先從最底層的調用開始看
在單步證明的調用中可以看到，這筆交易的用戶信息是保存在auth字段中的
func (m *ChallengeManager) IssueOneStepProof(
ctx context.Context,
oldState *ChallengeState,
startSegment int,
) (*types.Transaction, error) {
position := oldState.Segments[startSegment].Position
proof, err := m.executionChallengeBackend.GetProofAt(ctx, position)
if err != nil {
return nil, fmt.Errorf("error getting OSP from challenge %v backend at step %v: %w", m.challengeIndex, position, err)
}
return m.challengeCore.con.OneStepProveExecution(
m.challengeCore.auth, // 用戶信息保存在這個字段
m.challengeCore.challengeIndex,
challengegen.ChallengeLibSegmentSelection{
OldSegmentsStart: oldState.Start,
OldSegmentsLength: new(big.Int).Sub(oldState.End, oldState.Start),
OldSegments: oldState.RawSegments,
ChallengePosition: big.NewInt(int64(startSegment)),
},
proof,
)
}
具體如何使用可以繼續點進去看，最終是auth中包含一個變量（函數類型的變量），由這個變量進行簽名，（我們需要找到的這個函數的生命周期，也就是密鑰的生命周期）。
那么繼續往上看，看這個challengeManager的構造方法
func NewChallengeManager(
ctx context.Context,
l1client bind.ContractBackend,
auth *bind.TransactOpts,
fromAddr common.Address,
challengeManagerAddr common.Address,
challengeIndex uint64,
val *StatelessBlockValidator,
startL1Block uint64,
confirmationBlocks int64,
) (*ChallengeManager, error) {
...
return &ChallengeManager{
challengeCore: &challengeCore{
con: con,
challengeManagerAddr: challengeManagerAddr,
challengeIndex: challengeIndex,
client: l1client,
auth: auth, // 也就是上面的auth
actingAs: fromAddr,
startL1Block: new(big.Int).SetUint64(startL1Block),
confirmationBlocks: confirmationBlocks,
},
blockChallengeBackend: backend,
validator: val,
wasmModuleRoot: challengeInfo.WasmModuleRoot,
maxBatchesRead: challengeInfo.MaxInboxMessages,
}, nil
}
可以看到auth是上面傳遞過來的bind.ContractOpts
繼續往上面看,auth來自與Builder這個結構，好在這個結構的構造函數只被調用過一次（我們及假設唯一的構造得到的auth就是我們要找的auth，中間沒有發生更改）
func NewBuilder(wallet ValidatorWalletInterface) (*Builder, error) {
randKey, err := crypto.GenerateKey()
if err != nil {
return nil, err
}
builderAuth := wallet.AuthIfEoa()
var isAuthFake bool
if builderAuth == nil {
// Make a fake auth so we have txs to give to the smart contract wallet
builderAuth, err = bind.NewKeyedTransactorWithChainID(randKey, big.NewInt(9999999))
if err != nil {
return nil, err
}
isAuthFake = true
}
return &Builder{
builderAuth: builderAuth,
wallet: wallet,
L1Interface: wallet.L1Client(),
isAuthFake: isAuthFake,
}, nil
}
builder的auth有兩種途徑，一種是 AuthIfEoa 也就是從eoa中解析私鑰，一種是自己生成私鑰
那么關鍵在與這里的wallet是什么（也就是現在從跟蹤auth轉移到跟蹤wallet）
最終發現wallet在creatNoteImpl方法里面構造的
var wallet staker.ValidatorWalletInterface = validatorwallet.NewNoOp(l1client, deployInfo.Rollup)
if !strings.EqualFold(config.Staker.Strategy, "watchtower") {
if config.Staker.UseSmartContractWallet || (txOptsValidator == nil && config.Staker.DataPoster.ExternalSigner.URL == "") {// 合約賬戶
var existingWalletAddress *common.Address
if len(config.Staker.ContractWalletAddress) > 0 {
if !common.IsHexAddress(config.Staker.ContractWalletAddress) {
log.Error("invalid validator smart contract wallet", "addr", config.Staker.ContractWalletAddress)
return nil, errors.New("invalid validator smart contract wallet address")
}
tmpAddress := common.HexToAddress(config.Staker.ContractWalletAddress)
existingWalletAddress = &tmpAddress
}
wallet, err = validatorwallet.NewContract(dp, existingWalletAddress, deployInfo.ValidatorWalletCreator, deployInfo.Rollup, l1Reader, txOptsValidator, int64(deployInfo.DeployedAt), func(common.Address) {}, getExtraGas)
if err != nil {
return nil, err
}
} else {
if len(config.Staker.ContractWalletAddress) > 0 {
return nil, errors.New("validator contract wallet specified but flag to use a smart contract wallet was not specified")
}
wallet, err = validatorwallet.NewEOA(dp, deployInfo.Rollup, l1client, getExtraGas)
if err != nil {
return nil, err
}
}
}
繼續跟蹤我們得到wellet中的驗證方法是由txOptsValidator提供的
向上繼續找txOptsValidator
最重找到mainImpl
if sequencerNeedsKey || nodeConfig.Node.BatchPoster.ParentChainWallet.OnlyCreateKey {
l1TransactionOptsBatchPoster, dataSigner, err = util.OpenWallet("l1-batch-poster", &nodeConfig.Node.BatchPoster.ParentChainWallet, new(big.Int).SetUint64(nodeConfig.ParentChain.ID))
if err != nil {
flag.Usage()
log.Crit("error opening Batch poster parent chain wallet", "path", nodeConfig.Node.BatchPoster.ParentChainWallet.Pathname, "account", nodeConfig.Node.BatchPoster.ParentChainWallet.Account, "err", err)
}
if nodeConfig.Node.BatchPoster.ParentChainWallet.OnlyCreateKey {
return 0
}
}
if validatorNeedsKey || nodeConfig.Node.Staker.ParentChainWallet.OnlyCreateKey {
l1TransactionOptsValidator, _, err = util.OpenWallet("l1-validator", &nodeConfig.Node.Staker.ParentChainWallet, new(big.Int).SetUint64(nodeConfig.ParentChain.ID))
if err != nil {
flag.Usage()
log.Crit("error opening Validator parent chain wallet", "path", nodeConfig.Node.Staker.ParentChainWallet.Pathname, "account", nodeConfig.Node.Staker.ParentChainWallet.Account, "err", err)
}
if nodeConfig.Node.Staker.ParentChainWallet.OnlyCreateKey {
return 0
}
}
我們得到l1TransactionOptsValidator是使用nodeConfig.Node.Staker.ParentChainWallet 這個配置項得到的.
最終的數據結構張這個樣子
type WalletConfig struct {
Pathname string `koanf:"pathname"`
Password string `koanf:"password"`
PrivateKey string `koanf:"private-key"`
Account string `koanf:"account"`
OnlyCreateKey bool `koanf:"only-create-key"`
}
繼續點到OpenWallet可以看到他是如何處理這些配置項的
在有私鑰的情況下最終會走到這個方法
func NewKeyedTransactorWithChainID(key *ecdsa.PrivateKey, chainID *big.Int) (*TransactOpts, error) {
keyAddr := crypto.PubkeyToAddress(key.PublicKey)
if chainID == nil {
return nil, ErrNoChainID
}
signer := types.LatestSignerForChainID(chainID)
return &TransactOpts{
From: keyAddr,
Signer: func(address common.Address, tx *types.Transaction) (*types.Transaction, error) { // signer就是我們一直再找的在發送交易時使用到的簽名方法
if address != keyAddr {
return nil, ErrNotAuthorized
}
signature, err := crypto.Sign(signer.Hash(tx).Bytes(), key)
if err != nil {
return nil, err
}
return tx.WithSignature(signer, signature)
},
Context: context.Background(),
}, nil
}
從這里看出來，私鑰始終保存在signer這個方法中，在整個使用過程中沒有將私鑰作為參數傳遞的情況。
如果使用的是filekey+密碼的情況會進入到這個方法
func NewKeyStoreTransactor(keystore *keystore.KeyStore, account accounts.Account) (*TransactOpts, error) {
log.Warn("WARNING: NewKeyStoreTransactor has been deprecated in favour of NewTransactorWithChainID")
signer := types.HomesteadSigner{}
return &TransactOpts{
From: account.Address,
Signer: func(address common.Address, tx *types.Transaction) (*types.Transaction, error) {
if address != account.Address {
return nil, ErrNotAuthorized
}
signature, err := keystore.SignHash(account, signer.Hash(tx).Bytes())
if err != nil {
return nil, err
}
return tx.WithSignature(signer, signature)
},
Context: context.Background(),
}, nil
}
程序會根據filekey構造一個keystore,后續簽名都是在keystore中簽名
注意filekey的密碼是在終端控制臺輸入的,其中的readPass函數如下
func readPass() (string, error) {
bytePassword, err := term.ReadPassword(syscall.Stdin)
if err != nil {
return "", err
}
passphrase := string(bytePassword)
passphrase = strings.TrimSpace(passphrase)
return passphrase, nil
}
浙公網安備 33010602011771號